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ABSTRACT 


While  Linear  Prograraning  (LP)  is  acknowledged  to  be  a  powerful 
technique  for  obtaining  optimal  production  rates,  there  remains  the 
problem  of  making  an  LP  model  usable  as  the  basis  for  day-to-day 
decision-making.   This  paper  describes  the  design  and  construction 
of  a  support  system  allowing  a  group  of  managers  to  use  an  LP 
model  as  a  decision-making  tool.   The  particular  context  is  meat- 
packing, but  the  work  is  relevant  in  any  situation  where  an 
optimization  technique  is  to  be  used  as  the  basis  of  a  planning 
and  control  system  involving  many  controllable  variables  and  a 
need  for  timely  information. 
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Introduction  and  Overview 

The  Aggregate  Production  Scheduling  problem  may  be  thought  of 
as  the  determination  of  the  rates  of  resource  utilization  in  the  pro- 
duction process.  This  paper  attacks  the  design  of  an  interface  be- 
tween a  powerful  Aggregate  Production  Scheduling  technique.  Linear 
Programming  or  LP,  and  the  information  and  decision  system  used  by  a 
group  of  managers  charged  with  responsibility  for  day-to-day  resource 
allocation  decisions.  The  context  is  the  (pseudonymous)  Peerless 
Packing  Company  where  a  group  of  men  called  provlsioners  plan  and  con- 
trol the  rates  at  which  raw  materials  are  bought  and  allocated  to  pro- 
duction, by-products  are  sold,  and  finished  goods  are  placed  into 
inventory.  The  provisioners  control  roughly  1,000  different  rates, 
and  LP  offers  them  the  potential  for  a  truly  global  and  economic  plan- 
ning model.  Moreover,  LP  by-product  information  is  useful  for  making 
decisions  about  marginal  changes  in  the  plan. 

The  existence  of  a  good  technique  like  LP,  or  even  of  an  LP 
model  of  the  Peerless  Operations  still  leaves  us  short  of  a  useful 
tool  for  management.   Two  problems  arise  which  must  be  resolved: 

First,  prices  of  raw  materials  change  rather  rapidly.  Like  any 
profit  optimization  technique,  LP  is  sensitive  to  price  changes.   This 
fact  forces  us  to  design  our  system  both  to  respond  quickly  when 
necessary  and  to  produce  plans  with  inherently  long  life.  While  this 
paper  considers  these  points,  they  are  more  fully  discussed  in 
Sprague  (16). 


Second,  the  LP  model  must  be  made  easy  to  use,  e.g.  the  reports 
prepared  for  the  managers  must  be  clear  and  meaningful,  etc.   This 
paper  is  concerned  primarily  with  this  part  of  the  task. 

In  the  following  sections  we  describe  the  provisioning  environment 
ac  Peerless  and  the  LP  model  constructed  to  aid  in  planning.  We  then 
propose  an  "ideal"  system  for  making  the  LP  model  useful  to  management. 
While  we  believe  that  the  "ideal" system  is  feasible,  given  sufficient 
resources,  it  could  not  be  built  at  Peerless.  At  a  second  level  of 
consideration,  then,  is  the  problem  of  how  much  of  the  "ideal"  system 
could  be  realized  where  adequate  resources  were  unavailable.  We  detail 
the  design  and  construction  of  our  LP-support  system  which  did  indeed 
preserve  most  features  of  the  "ideal"  system  with  severely  limited 
resources. 

The  Provisioning  Environmnet  at  Peerless 

Peerless  is  a  pork-oriented  meat  packer  which  lost  several  millions 
on  sales  of  $300  million  in  fiscal  1966.  For  the  purposes  of  this 
Study,  Peerless  may  be  considered  to  be  a  pure  price-taker  in  both 
buying  and  selling,  and  to  have  only  one  plant  (located  in  Cedarton, 
Iowa),  though  neither  is  strictly  true.  The  manufacturing  process  at 
Peerless  begins  with  live  hogs  and  ends  with  several  thousand  finished 
products  ranging  from  whole  fresh  pork  loins,  through  processed  meats 
such  as  bacon,  hams  and  sausage,  to  portion-controlled  frozen  foods. 

In  order  to  balance  out  its  production  process.  Peerless  also  does 
*I.e.  unable  to  influence  market  prices. 


substantial  trading  in  primal  cuts  (major  components  of  hogs^  such  as 
green  (uncured)  hams,  green  bellies,  and  loins).  For  example,  Peerless 
has  a  considerable  consumer  franchise  for  its  bacon,  so  has  long  been 
a  net  buyer  of  bellies;  but  it  is  always  selling  loins,  since  it  is 
weak  in  fresh  meat.  There  are  also  several  components  purchased  for 
use  in  manufacturing,  such  as  cans,  cure,  and  beef  for  sausage.   Simi- 
larly, many  by-products  are  sold,  including  relatively  unprocessed 
Items  like  skin  and  hair,  and  highly  refined  products  like  lard. 

A  description  of  the  organization  which  now  solves  the  aggregate 
production  scheduling  problem  for  Peerless  is  in  order;  imbedded  within 
it  will  be  consir"  rable  information  about  the  nature  of  its  production 
process  (see  Figure  I).  We  should  begin  at  the  end  of  the  production 
lines  since  this  is  a  convenient  aggregation  point  —  many  of  the 
thousands  of  final  products  already  mentioned  differ  from  one  another 
only  in  final  packaging,  and  many  others  are  insignificant  in  volvmie. 
There  are  perhaps  300  unique  and  important  final  products. 

The  production  scheduling  function  for  these  final  products  is 
performed  by  several  men  known  as  product  managers.   Each  product  mana- 
ger serves  as  the  interface  between  the  sales  and  production  operations 
for  one  particular  category  of  product.   He  is  responsible  for  trans- 
lating a  demand  figure  supplied  by  sales  into  a  feasible  production 
schedule,  and  for  deciding  what  priorities  should  be  attached  to  each 
individual  product  when  all  demand  cannot  be  met.   He  must  also  cope 
with  overstocks,  old  meat,  and  so  on.  While  he  does  not  have  the  final 
say  on  pricing,  he  is  always  consulted  before  price  changes  are  pro- 
mulgated and  before  special  marketing  efforts  are  undertaken.  When 
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the  product  manager  is  dealing  with  a  perishable  product  such  as 
fresh  sausage  (bologna,  etc.),  his  life  is  complicated  by  short  inven- 
tories, high  spoilage  costs,  and  market  demand  fluctuations.  When  he 
is  dealing  with  a  long-lived  product  like  canned  ham,  he  is  spared  some 
of  the  day-to-day  fire-fighting.  But  he  must  work  against  long-term 
forecasts  of  demand  and  prices,  making  the  daily  decision  as  to 
whether  or  not  to  put  meat  into  cans,  based  on  his  raw  material  replace- 
ment cost  which  fluctuates  hourly. 

Each  product  manager  depends  for  his  raw  materials  on  the  provision- 
ers.  who  are  responsible  for  supplying  primal  cuts  to  the  manufacturing 
operations.  The  provisioners '  major  sources  are  the  internal  kill-and- 
cut  operation  and  the  open  market.  Unfortunately,  every  primal  cut  is 
available  in  several  sizes  at  different  prices  and  different  yields  in 
manufacture.  The  provisioner  cannot  control  the  mix  of  primals  pro- 
duced internally,  but  he  can  control  the  mix  of  purchased  primals;  he 
has  access  to  freezer  space  for  hedging  and  filling  gaps  in  availability, 
and  he  is  responsible  for  selling  any  primals  not  required  by  the  manu- 
facturing operations. 

The  provisioner  has  another  sensitive  duty:   he  must  allocate 
finite  raw  material  resources  among  the  product  managers  in  those  cases 
where  there  is  not  enough  of  a  desirable  size  to  go  around.  This  in- 
volves substitution  of  other  sizes,  with  corresponding  changes  in  ex- 
pected yields  and  in  the  quality  of  finished  product.  The  provisioner 
is  faced  with  rapidly  varying  prices  for  primals,  both  in  buying  and 


selling;  the  quantities  available  for  purchase  and  wanted  by  potential 
buyers  also  vary  daily.   Finally,  the  quality  of  purchased  primals  is 
variable  but  generally  lower  than  that  achieved  internally  because  of 
the  tendency  of  sellers  to  cull  their  excess  primals  before  offering 
the  lower-quality  ones  to  the  market. 

It  is  not  surprising  that  provisioners  prefer  their  own  product, 
for  which  they  are  dependent  on  the  hog  buyer.   The  hog  buyer  acquires 
hogs  on  the  open  market  for  the  kill-and-cut  operation.   He  determines 
how  many  hogs  are  to  be  killed  by  day  and  by  week.   He  has  considerable 
flexibility  because  there  are  three  ways  to  control  the  daily  rate  of 
klll-and-cut:  overtime,  extra  shifts,  and  chain  speed.   He  need  not 
work  a  full  week,  but  Peerless  pays  each  worker  In  cut-and-kill  for 
35  hours  per  week  at  minimum,  so  he  tries  to  keep  the  facilities  and 
men  busy. 

Hogs  are  a  highly  variable  commodity  and,  while  prices  are  quoted 
on  108  different  sizes  and  grades  of  hog,  each  of  which  tends  to  cut 
out  differently,  the  hog  buyer  has  no  effective  control  over  the  mix 
of  hogs  purchased  at  any  time.   He  is  aided  by  the  law  of  large  numbers 
in  that  the  mix  tends  to  be  relatively  constant  from  day  to  day,  chang- 
ing over  the  year  to  reflect  stages  in  the  growth  cycle. 

The  hog  buyer's  most  potent  decision  tool  is  a  daily  report  show- 
ing the  profit  which  would  have  been  earned  on  every  hog  killed  yester- 
day is  the  hogs  had  been  bought  at  the  Chicago  market  price,  killed  and 
cut  at  exactly  standard  cost,  and  immediately  sold  as  primal  cuts  and 
offal  at  the  Chicago  market  price.   The  usefulness  of  this  tool  is  ob- 


viously  limited  by  the  simple  fact  that  Peerless  is  not  primarily  in 
the  business  of  selling  primal  cuts,  and  by  the  fact  that  nothing  is 
ever  done  at  standard  cost,  especially  when  guaranteed  wages  enter  the 
picture. 

Thus,  the  hog  buyer  feeds  the  provisioners,  and  they  feed  the  prod- 
uct managers.   It  is  clear  that  the  provisioning  function  is  the  center 
of  the  whole  operation.  We  shall  assert  that  this  three-stage  decision- 
making process  Is  a  reasonable  attempt  at  coping  with  the  complexity 
of  the  manufacturing  process  and  the  uncertainty  of  market  prices. 

There  are  about  1,000  inqjortant  levels  to  be  controlled  in  the  con- 
version of  hogs  to  money  at  Peerless,  including  several  hundred  within 
the  production  process  which  arise  from  the  many  alternative  ways  in 
which  one  single  finished  product  can  be  created.  These  make  the  aggre- 
gate production  scheduling  job  entirely  too  much  for  one  man;  but  one 
alternative,  decentralized  decision-making  with  local  data  (Cf  the  hog 
buyer),  is  a   priori  suboptimal. 

In  fact,  the  provisioning  function  at  Peerless  is  currently  handled 
by  several  men  under  the  general  supervision  of  the  Chief  Provisioner 
whose  responsibilities  include  both  "provisioning"  and  "production." 
The  individual  provisioners  have  individual  product-line  responsibility 
and,  except  for  the  odd  phone  call,  they  operate  independently  of  one 
another.  Once  a  week,  they  meet  to  plan  for  the  following  10-day  period. 
Conflicts  are  resolved  by  consultation  among  the  Chief  Provisioner  and 
the  affected  provisioners  and/or  product  managers. 


Using  Carroll's*  terminology,  we  may  characterize  the  provision- 
ing system  at  Peerless  as  a  set  of  local-real-time  systems,  tied  by  a 
loose  communication  net,  and  supervised  by  a  global-periodic  system 
(the  weekly  meeting).   It  is  doubtful  whether  any  other  organization 
vould  be  more  effective.  At  the  risk  of  sloganeering,  we  should  point 
out  that  such  an  arrangement  is  modular  and  open-ended,  and  that  it 
permits  the  Chief  Provisioner  to  manage  by  exception.   Unless  one  wishes 
to  coiqpletely  overthrow  the  present  system,  thereby  incurring  what  are 
presumably  large  changeover  costs,  one  must  support  the  local-real- 
time systems  by  means  of  better  plans  and  better  tools  with  which  to 
fight  fires,  and  one  must  support  the  global -periodic  system  with  better 
Information.  With  LP,  one  can  supply  the  global-periodic  system  with 
truly  global,  truly  optimal  results. 

But  the  present  system  permits  the  provisioners  to  gather  when- 
ever there  is  a  crisis  of  sufficient  size  to  justify  a  meeting.  The 
production/provisioning  planning  system  should  also  be  able  to  help 
with  such  ad  hoc  meetings.  Thus,  it  must  be  capable  of  quick  response 
as  well  as  transparent  to  a  variable  time  between  operations  of  the 
global-periodic  system  (meetings). 

So  far  we  have  considered  the  needs  of  the  provisioner  only  in 
general  terms,  and  this  consideration  has  yielded  a  very  general  out- 
line of  the  system  needed  to  support  him.  We  will  now  use  the  term 
"provisioner"  to  include  the  functions  performed  by  the  hog  buyer  and 

*  See  (9) . 


product  managers,  and  we  go  into  more  detail  about  the  function  of  the 
provisioners. 

First,  we  consider  the  routine  global-periodic  provisioning 
functions: 

1.  Acquisition:   How  many  hogs  should  be  purchased?  On  what 
schedule?   In  which  markets?  How  many  of  each  of  25  types 
and  sizes  of  primal  cuts  should  purchased? 

2.  Allocation:   How  much  of  each  primal  cut  produced,  purchased, 
or  removed  from  the  freezer  should  be  allocated  to  the  produc- 
tion of  each  final  product? 

3.  Disposal:   How  much  of  each  primal  cut  should  be  sold  on  the 
open  market?  At  what  price?  On  what  schedule?  To  whom? 
How  much  of  each  primal  cut  should  be  frozen  for  later  use? 

These  decisions  are  constrained  by  such  factors  as  cash  available, 
primals  available  In  the  market,  demand  for  prlmals  in  the  market,  hogs 
available,  plant  capacities,  demand  for  finished  product,  and  so  on. 
They  are  obviously  highly  interactive  one  with  another. 

Now  we  consider  a  sampling  of  local-real-time  provisioning 
functions: 

4.  Acquisition:  Another  packer  has  offered  us  a  carload  of 
picnics  at  one  cent  off  market  price.  Do  we  accept? 

5.  Allocation:  A  sudden  order  for  a  large  amount  of  some  fin- 
ished product  cannot  be  filled  by  present  stocks  of  finished 
product,  in-process  product,  or  even  allocated  raw  materials. 
Do  we  acquire  more  raw  materials?  Do  we  acquire  more  raw 
materials  (primals),  substitute  another  size  of  the  needed 
primal,  refuse  the  order,  or  do  some  combination  of  these? 

6.  Disposal:  A  carload  of  loins  is  growing  old,  but  at  present 
market  price  we  take  a  loss  of  two  cents  on  each  pound.  Do 
we  sell  at  a  loss? 
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7.   Price  Change:   Green  hams  are  up  two  cents  this  morning. 
We  suspect  that  this  is  a  temporary  rise  which  will  never 
be  reflected  in  increased  price  for  finished  product.  Do 
we  suspend  ham  processing  and/or  sell  off  our  green  hams? 


We  now  proceed  to  describe  what  will  be  referred  to,  for  want  of 
a  better  term,  the  "ideal"  system.   In  so  doing  we  indulge  in  two 
fantasies.  First  we  assume  that  the  payoff  from  the  use  of  this  sys- 
tem will  justify  its  running  cost.  For  this  purpose  we  assimie  that  it 
will  consume  about  1/8  of  the  available  time  on  a  data-processing  sys- 
tem costing  $400,000/year,  or  $50,000  in  data-processing  costs/year. 
In  addition,  we  allow  $50,000  more  for  maintenance  and  special  data  col- 
lection. Routine  data-collection  costs  are  assxuned  to  be  absorbed 
elsewhere  (as  described  below).   In  order  to  justify  its  costs  then. 
It  must  save  (or  produce)  $100,000/year,  or  0.04%  of  sales.  Our 
-second  fantasy  is  to  assume  that  Peerless  can  support  the  $400,000  data 
processing  system  mentioned  above.  This  is  about  0,167o  of  sales  and 
is  not  a  priori  unreasonable,  but  it  _is  unreasonable  in  Peerless'  pres- 
ent situation.   Nonetheless,  we  must  assume  it  for  now. 

Several  more  assun^jtions  are  necessary,  all  of  which  are  reason- 
able. First  we  assume  that  certain  key  pieces  of  data  are  available 
at  no  incremental  cost  from  the  accounting  system.  When  this  project 
was  begun  Peerless  was  in  the  process  of  building  and  implementing 
PYRAMIDS  (Plant  Yield  Reporting  and  Management  Information  Dissemina- 
tion System).  PYRAMIDS  (which  at  this  writing  is  in  regular  operation) 
was  to  contain  all  price,  inventory,  shipment,  and  yield  information 
as  a  matter  of  course,  thus  eliminating  the  need  for  separate  routine 
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data  collection.   Another  assumption  is  that  the  role  and  nature  of 
the  men  now  serving  as  provisioners  will  not  change  substantially. 

Finally,  we  adopt  a  convention  for  describing  the  LP  model  on 
which  the  system  is  based.  The  model  will  be  described  in  terms  ac- 
ceptable  to  the  "bounded  variable  algorithm"  in  which  upper  and  lower 
bounds  may  be  attached  directly  to  the  columns,  primarily  because  the 
majority  of  limitations  encountered  in  formulating  this  model  approp- 
riately affect  only  a  single  column.   In  the  few  cases  where  a  real 
inequality  row  is  needed,  it  costs  only  one  new  column  to  convert  it 
to  an  equality  row  with  explicit  bounds  on  the  newly-created  column. 
This  results  in  a  much  more  compact  model  (In  this  case,  there  would 
be  2300  or  more  rows  if  every  bound  required  a  new  row),  and  means 
that,  since  every  row  is  a  structural  equality  not  subject  to  the 
control  of  management,  the  inqjortant  shadow  prices  —  those  for  real 
resources  --  are  grouped  naturally  with  the  remaining  information 
about  the  colxanns.   Thus  the  user  need  not  maintain  any  sort  of  dic- 
tionary to  guide  him  from  a  particular  column  to  corresponding  bound 
rows.  The  compactness  means  that  the  model  can  be  made  to  work  on  a 
smaller  machine  than  would  otherwise  be  required,  though  no  reduction 
in  solution  time  is  inqjlied.   The  output  is  somewhat  more  compact, 
since  it  is  unnecessary  to  present  information  about  the  rows.  For 
all  these  reasons,  the  model  will  be  built  and  maintained  as  if  it 
were  in  the  bounded  variable  form,  even  though  it  may  well  be  run  on 
a  machine  for  which  no  such  code  currently  exists. 


*  Hadley  (3) 
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Model  Description 

Before  describing  the  "ideal"  system  we  should  discuss  the  LP 
model  underlying  the  planning  process.   The  general  LP  problem,  cast 
into  a  form  consistent  with  our  model  formulation  is: 


N 
Maximize     Z  -  ^  C^X^ 

J-1  -^  ■* 


Subject  to: 


N 
^  a^jXj  -  0  ;    i  -  1,  M 


J»l 


Lj  £:  Xj  £  Uj   ;    J  -  1,  N 

where  Xi  is  the  value  of  the  j^"  variable  or  quantity  to  be  determined 
(e.g. J  pounds  of  a  primal  to  be  bought);   C^  is  the  price  of  variable  j; 
a^j  la  the  coefficient  in  column  j  and  row  i;  Lj  is  a  lower  bound  for 
variable  j ;  U^  is  an  upper  bound  for  variable  j .  There  are  N  variables 
or  columns  and  M  rows  or  equations. 

An  LP  solution  is  feasible  when  the  values  of  the  Xj's  satisfy 
all  M  equations  and  fall  within  their  respective  bounds.  An  LB  solution 
is  optimal  when  there  exists  no  feasible  change  in  the  values  of  the 
Xj's  which  increases  the  value  of  Z,  When  a  solution  becomes  optimal, 
each  variable  has  associated  with  it  a  level  or  recommended  quantity 
and  a  C-range  or  range  over  which,  cet.  par.,  the  price  of  this  vari- 
able may  vary  without  loss  of  optimality.   The  level  and  the  C-range 
are  the  two  most  in?)ortant  elements  of  the  plan  drawn  for  each  variable. 
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The  actual  model  (see  Figure  2)  is  divided  into  ten  logical 
units: 

1.  Kill:   one  variable  representing  total  hogs  purchased  is 
divided  up  into  108  quantities  of  "live  weight"  of  different 
kinds  of  hog.   The  model  is  also  given  the  opportunity  to 
purchase  one  pound  of  each  kind  of  hog  separately.   This 
section  requires  approximately  220  columns  and  110  rows. 

2.  Cut-out:   108  types  of  hog  are  converted  to  35  types  of 
primal.   Labor  costs  are  assessed  and  by-products  accounted 
for.   This  section  required  approximately  100  colvmins  and 
40  rows, 

3.  Hams:   cut-out  primal  hams  are  sumned  with  purchased  and 
thawed  hams  to  give  total  ham  availability.   This  is  dis- 
tributed between  sales,  freezing,  and  production.  Hams  to 
production  are  allocated  to  smoking  and/or  canning.   Each 

ham  is  allocated  to  a  particular  process  ending  in  one  or  more 
finished  products.   Labor  costs  and  by-products  are  accounted 
for.  This  section  requires  approximately  300  columns  and 
170  rows. 

4.  Bellies 

5.  Picnics 

6.  Loins 

7.  Butts 

8.  Ribs:   These  sections  are  somewhat  less  complex  than  hams, 
but  the  same  general  formulations  are  used.  These  sections 
total  approximately  300  columns  and  160  rows. 

9.  Sausage:   This  section  serves  as  a  sink  for  by-products  pro- 
duced in  all  other  sections.  Because  each  material  is  at 
least  potentially  usable  in  every  sausage,  each  separate 
kind  of  sausage  requires  approximately  50  columns  and  10  rows, 
for  a  total  of  1000  columns  and  200  rows, 

10.   Cost  and  Profit:   This  section  merely  sums  up  various  labor 
costs  and  facility  usage  data  for  management  use.   It  re- 
quires only  about  10  extra  rows  and  10  extra  columns. 


Figure  2  accurately  shows  the  relationship  between  these  sections; 
e.g.,  it  is  true  that  hams  and  bellies  interact  only  at  the  points  of 
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Figure  2 
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cut-out,  sausage,  and  cost  and  profit;  and  it  is  true  that  all  sections 
feed  the  sausage  section. 

The  Ideal  System;   General  Philosophy 

Having  described  both  the  provisioning  environment  and  the  form 
of  an  appropriate  LP  model,  we  now  describe  the  "ideal"  system  and 
Its  role  as  an  interface. 

One  possible  requirement  of  the  ideal  system  is  that  it  dominate 
the  present  system.  This  is  relatively  easy  to  accomplish,  since  it 
Is  always  possible  to  invoke  the  present  system  for  any  task  which  is 
better  accomplished  by  present  methods.   However,  the  power  of  the 
present  system  comes  in  some  part  from  the  fact  that  the  individual 
provisioners  are  always  in  possession  of  quite  recent  information  about 
the  current  status  of  their  product  areas.   So  an  obvious  requirement 
on  the  ideal  system  is  that  it  supply  provisioners  with  information  at 
least  as  current  as  what  they  now  have  and,  conversely,  that  they  be 
able  to  supply  it  with  current  information  when  such  would  help.  Along 
this  dimension,  the  ideal  system  looks  like  an  information  storage  and 
retrieval  system. 

Another  desirable  characteristic  is  that  the  system  be  able  to  ans- 
wer such  questions  as  "What  would  happen  if  an  extra  carload  of  bellies 
were  made  available  to  the  plant?"  This  is  the  essential  characteristic 
of  a  simulation  system. 

And,  we  want  to  be  able  to  ask  the  system  for  the  optimal  plan 
for  the  following  week,  based  on  current  or  projected  information. 
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In  this  regard,  we  are  talking  about  a  conventional  optimization  tech- 
nique . 

Since  the  Chief  Provisioner  can  call  a  special  meeting  to  invoke 
the  present  system  at  any  time,  it  is  not  unreasonable  to  expect  the 
Ideal  system  to  respond  as  quickly.   So  the  ideal  system  must  consist 
of  data-collection  and  editing  subsystems,  an  optimization  subsystem, 
and  report  generation  subsystems.   It  must  operate  as  a  true  on-line 
system  or  at  worst  as  a  remote  job-entry  system  with  rapid  turn-around 
to  provide  the  requisite  level  of  response  time. 

The  following  sections  describe  the  required  subsystems.  The 
descriptions  are  written  as  if  the  data-processing  system  available 
had  massive  random-access  storage  capability  and  the  ability  to  create 
and  use  symbolically-named  files.  While  neither  of  these  features  is 
strictly  necessary,  both  are  great  conveniences  for  the  system  designer. 
The  descriptions  also  assiane  a  command  language  which  can  be  used  to 
drive  the  subsystems.   Such  command  languages  are  an  integral  part  of 
modern  remote- job-entry  oriented  operating  systems  such  as  OS/360, 

The  Ideal  System:  Data  Generation  and  Editing 

The  data-generation  and  editing  subsystems  have  at  least  the 

following  capabilities: 

1.  FORECAST: 

Using  the  PYRAMIDS  files  of  shipment  and  order  data,  the 
system  generates  forecasts  of  sales  for  all  finished  products 
for  some  arbitrary  period.   It  places  these  forecasts  in  a  file 
called: 
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MACHINE  .  FORECASTS  ,  MMDD 
where  MMDD  Is  today's  date. 

2.  FCSTUPDATE: 

The  system  delivers  the  information  in  the  latest  file 
named  MACHINE  .  FORECASTS  .  MMDD  or  HUMAN  ,  FORECASTS  ,  MMDD 
to  the  user's  console  or  remote  printer.   It  then  accepts  the 
user's  revisions  to  these  forecasts.   It  enters  the  modified 
forecasts  in  a  file  called: 

HUMAN  .  FORECASTS  .  MMDD 

\ 
\ 

3.  MDDSTRUCTDRE  ALPHA  BETA 

The  system  accepts  changes  to  the  LP  structural  equations 
contained  in  file 

ALPHA  .  STRUCTURE 

and  places  the  changed  structural  equations  in  file 

BETA  .  STRUCTURE 

4.  DRAWSTATUS  GAMMA  DELTA 

The  system  searches  the  file 

GAMMA  .  STRUCTURE 

to  find  what  price  and  quantity  information  is  required  to  run 
the   model.   It  then  searches  the  PYRAMIDS  file  and  the  latest 
version  of 

HUMAN  ,  FORECASTS  .  MMDD 

to  fill  in  prices  and  quantities.   Some  prices  will  require 
special  manipulation.  For  example,  PYRAMIDS  keeps  all  prices 
as  positive  numbers.   Some  will  need  to  be  made  negative  for  the 
purposes  of  the  LP,   In  the  case  of  long-life  products,  some 
deduction  from  selling  price  will  be  required  to  account  for  hold- 
ing costs  until  expected  sale.  For  guidance  in  these  operations, 
the  system  will  refer  to  file 

DELTA  ,  PRICERULES 

The  result  will  be  a  complete  LP  problem  ready  to  be  run  in 
the  file 
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GAMMA  .  STATUS 

It  can  be  argued  that  this  subsystem  permits  great  generality 
In  model  structure  (via  MDDSTRUCTURE)  and  in  price  manipulation 
(via  DRAWSTATUS) ,  but  that  it  is  slavishly  tied  to  price  and 
quantity  information  contained  in  the  PYRAMIDS  files.   This  is 
desirable  because  the  PYRAMIDS  files  must  be  correct  for  proper 
functioning  of  the  accounting  system.   However,  to  correct  the 
occasional  error  and  to  allow  the  user  to  try  out  "What  would 
happen  if  ...  "  questions,  we  also  require: 


5.   EDSTATUS  GAMMA  EPSILON 

This  permits  the  user  to  change  the  information  in  GAMMA 
STATUS,  filing  the  result  as  EPSILON  .  STATUS. 


The  Ideal  System;   Optimization 

The  optimize,  .ion  subsystem  supports  the  single  cosmand: 

OPTIMIZE  GAMMA 

The  system  takes  the  file 

GAMMA  .  STATUS 
and  converts  it  into  the  required  input  format  for  the  manufacturer's 
LP  package.   The  LP  code  then  takes  over,  returning  control  to  the  OP- 
TIMIZE command  when  done.   This  output  is  then  filed  under  the  name 

GAMMA  .  SOLUTION 
It  is  worthwhile  to  note  here  that  one  would  not  normally  write  his 
own  LP  package,  because  many  major  manufacturers  (IBM,  CDC,  UNIVAC, 
etc.)   supply  truly  excellent  LP  codes  for  their  larger  machines.   Such 
codes  are  characterized  by  large  capacity,  availability  of  coiH)rehensive 
start-up  and  post-optimality  procedures,  and,  just  as  important,  embody 
control  languages  allowing  a  limited  amount  of  external  logic  to  be 
performed  by  the  code  itself.   Thus  special  procedures  in  case  of  in- 
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feasibility  or  wildly  unlikely  solutions  can  be  specified  by 
the  user  as  part  of  his  input. 

The  Ideal  System;   Report  Generation 

The  report  generation  subsystem  has  at  least  the  following 
capabilities: 

I.   REPORT  GAMMA  ZETA 

Produces  for  the  user  a  report  of  the  model  described 
in  GAMMA  .  STATUS.   For  each  column  of  the  model  (remember 
that  we  have  no  need  for  row  information),  the  report  should 
confirm: 

Alphabetic  description  of  the  variable 

Objective-Function  Coefficient  (price) 

Lower  Bound  if  any 

Upper  bound  if  any 

Recomnend  Level  (Solution  Value) 

Activity  Status  (in  solution  or  not^  at  upper/lower  bound) 
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Haxlmum  Price  (Algebraically  maximum  value  of  objective 
function  coefficient  at  which  this  column's 
solution  status  remains  unchanged) 

Activity  Limiting  Maximum  Price 

Solution  Status  of  Limiting  Activity 

Miniimnn  Price 

Activity  Limiting  Minimum  Price 

Solution  Status  of  Limiting  Activity 

Marginal  Return  for  Increase  (Net  change  in  Objective 

Fxjnctlon  for  One-Unit  Increase  in  Activity  Level) 

MaxlsBStt  Level  (Before  Marginal  Return  for  Increase  Will  Change) 

Activity  Limiting  Maximum  Level 

Solution  Status  of  Limiting  Activity 

Marginal  Return  for  Decrease  (Probably  has^  but  may  not 

have,  same  magnitude  and  opposite  sign  as  Marginal 
Return  for  Increase) 

M^n1muIIl  Level 

Activity  Limiting  Minimum  Level 

^Solution  Status  of  Limiting  Activity 

This  represents  most  of  the  information  available  about  a  solution 
short  of  parametric  runs.   It  suffices  to  allow  the  user  to: 

a.  Base  a  plan  on  the  recomcended  levels 

b.  Base  marginal  decisions  on  the  price-and-constraint  range 
Information. 

In  order  to  prepare  this  report^  the  system  will  have  to  use  both 

files 

^  GAMM/^   .    SOLUTION 

GAMM/^   .    STATUS 
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For  convenience  in  later  use,  the  complete  report  should  be 
placed  in  a  file 

GAMMk   .    REPORT 

It  Is  likely  that  the  user  will  wish  to  suppress  some  of  the 
output  and/or  aggregation  techniques.   In  order  to  allow  this^ 
the  REPORT  command  allows  the  parameter  ZETA  which,  if  present, 
causes  the  system  to  build  the  user's  report  according  to  tables 
stored  in  file 

ZETA  .  FORMAT 

2.  COMPARE  GAMMA  OMEGA  ZETA 

Using  the  report  files  from  two  solutions  i.e. 

GAMMA  .  REPORT  and 

CMEGA  .  REPORT 
the  system  prepares  a  difference  report  according  to 

_JZETA  .  FORMAT 
and  presents  this  to  the  user. 

3.  PLAN  GAMMA  IOTA 

The  system  presents  file 

GAMMA  .  REPORT  or 
GAMMA  .  PLAN 
to  the  user,  who  enters  planned  levels  and  prices  wherever  his 
plan  differs  from  the  levels  and  prices  in  the  input  file.   When- 
ever he  does  not  enter  a  new  value,  the  number  given  in  the  input 
file  is  taken  as  the  planned  number.   The  result  is  filed  under 
the  name 
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IOTA  .  PLAN 

4.   CONTROL  IOTA  ZETA  ^ 

The  system  searches  the  PYRAHIDS  files  for  actual  performance 
figures  (amount  produced  or  allocated,  prices  realized,  etc.). 
It  then  searches 

IOTA  .  PLAN 
for  the  planned  numbers  and  produces  a  control  report  contrast- 
ing planned  and  achieved  numbers,  according  to  format  file  ZETA. 

How  the  Ideal  System  is  Used 

Let  us  suppose  that  the  system  is  now  in  use.  The  current  plan  is 

based  on  files 

CDRRENI  .  STATUS 

CURRENT  .  SOLUTION 

CURRENT  .  REPORT 

CURRENT  .  PLAN 

NORMAL  .  PRICERULES 

CURRENT  .  STRUCTURE 

NORMAL  .  FORMAT 

and  is  now  a  week  old.  It  is  time  to  prepare  next  week's  plan.  The 

sequence 

FORECAST 
FCSTUPDATE 

has  been  run.   Slight  changes  are  expected  in  plant  yields  due  to  a 

change  in  the  average  characteristics  of  hogs  available;  so,  we  have 

to  modify  the  structural  equations  of  the  model  accordingly.   Therefore, 

-MODSTRUCTURE  CURRENT  NEXT 
DRAWSTATUS   NEXT  NORMAL 
OPTIMIZE   NEXT 
REPORT  NEXT  NORMAL 
COMPARE  CUBJIENT  NEXT  NORMAL 
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Examining  the  difference  report  con^aring  CURRENT  and  NEXT^  we  see 
that  several  quantities  have  changed  greatly.   On  further  investiga- 
tion, we  see  that  prices  for  2  primal s  have  been  reversed  in  the  PYRAMIDS 
file.  We  cope  by  issuing 

EDSTATUS  NEXT  NEXT 
OPTIMIZE  NEXT 
REPORT  NEXT  NORMAL 
COMPARE  CURRENT  NEXT  NORMAL 

This  time,  our  examination  convinces  us  that  the  model  NEXT  Is 

satisfactory.  We,  therefore,  hold  our  weekly  planning  meeting  during 

(or  at  the  conclusion  of)  which  we  issue 

PLAN  NEXT 

and  enter  the  plan  for  the  week  ahead. 

From  this  point  on,  any  product  manager  or  provisioner  can  find 
out  the  current  plan  and  how  he  is  doing  in  con^arison  by  issuing, 
say, 

CONTROL  NEXT  HAMS 
where  the  file 

HAMS  .  FORMAT 
contains  instructions  to  select  just  the  ham  sector  of  the  report. 

Naw  suppose  the  provisioner  wants  to  know  whether  or  not  to  accept 
an  extra  carload  of  picnics.   In  most  cases,  the  regular  report  gives 
him  the  marginal  value  of  extra  pcinics.  If  he  doesn't  feel  confident 
about  this,  however,  he  can  try 

EDSTATUS  NEXT  SPECIAL 
and  create  a  new  file 

SPECIAL  .  STATUS 
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containing  the  information  that  extra  picnics  are  available.   He 

then  issues: 

OPTIMrZE  SPECIAL 

REPORT  SPECIAL  NOPAPER 

COMPARE  SPECIAL   NEXT   NORMAL 

where  the  file 

NOPAPER  .  FORM/VT 

•xq>presses  actual  production  of  the  regular  report^  but  does  allow 

creation  of  the  necessary  file 

SPECIAL  .  REPORT 

He  must  be  aware  that  the  sequence  above  compares  only  two  recom- 
mended solutions,  not  two  plans,  but  he  does  get  an  excellent  idea  of 
the  consequences  of  accepting  the  extra  picnics. 

The  system  as  described  above  is  thus  able  to  answer  virtually 
all  questions  of  the  type  posed  above.   In  addition^  we  need  only  re- 
quire that  forecast  information  and  realization  information  (the  lat- 
ter from  PYRAMIDS)  be  converted  into  weekly  rates  to  make  the  system 
absolutely  transparent  to  whether  planning  is  done  daily,  weekly, 
monthly,  or  at  any  intermediate  interval. 

The  system's  response  time  is,  of  course,  dependent  on  the  speed 
and  size  of  the  machine(s)  on  which  it  is  resident,  and  also  on  its 
-mode  of  operation  (on-line,  remote  batch,  normal  batch,  etc.);  but. 
In  most  cases,  one  day  would  seem  to  be  an  upper  bound  on  a  complete 
re-planning. 
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On  the  other  hand,  such  a  system  would  be  expensive  to  build,   (How 
expensive  it  would  be  is  impossible  to  estimate  at  this  level  of  detail 
in  description  and  without  a  particular  machine  and  operating  system  in 
mind.)  Once  built,  system  maintenance  would  be  modest,  since  the  system 
itself  consists  mainly  of  very  general  data-manipulation  subsystems. 
Maintenance  of  the  data  base  is  largely  absorbed  by  PYRAMIDS.  The  major 
flaw  in  this  "ideal"  system  is  that  its  use  would  require  either  some 
substantial  change  in  the  roles  of  the  provisioners  or  the  interposition 
of  a  cadre  of  technicians  between  them  and  the  system.  While  neither 
is  strictly  desirable,  the  latter  alternative  is  costly  and  likely  to 
introduce  errors.   In  the  long  run,  the  provisioners  probably  would 
find  it  desirable  to  become  intelligent  system  users  themselves. 

There  will  have  to  be  technicians,  of  course,  to  step  in  when 
solutions  are  infeasible,  unbounded,  or  unreasonable.  These  people 
should  preferably  combine  computer,  LP,  and  provisioning  expertise. 
Their  salaries  are  part  of  the  cost  of  running  this  system. 

Available  Resources 

In  reality.  Peerless  had  neither  the  large  EDP  installation  called 
for,  nor  the  personnel  corresponding  to  such  an  installation.   It 
will  be  convenient  to  organize  our  description  of  resources  which  were 
available  into  machine  and  human  categories. 

Machines;  Peerless  had  two  UNIVAC  1050 's,  each  of  which  had  five 
tape  drives,  reader,  punch,  and  printer.  While  the  project  was  in 
progress  the  core  storage  sizes  of  these  machines  were  in  flux,  but 
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neither  was  ever  larger  than  24,576  bytes  of  storage.   Initially, 
Peerless  also  had  a  UNTVAC  1004,  which  is  a  general  data-conversion 
machine  permitting  translation  between  any  valid  combinations  of 
cards,  magnetic  tape,  paper  tape  and  printed  output.   The  1004  was 
removed  when  one  of  the  1050 's  was  augmented  by  a  paper-tape  subsystem. 
In  addition.  Peerless  had  card-handling  equipment  oriented  toward 
UNIVAC  90-colximn  cards,  including  keypunches,  sorters,  duplicating 
punches,  and  the  like. 

EDP  Personnel;  Peerless  had  an  EDP  organization  consisting  of 
three  departments  (operations,  programming,  research)  reporting  in 
parallel  to  the  Vice  President  for  Administration;  the  operations  sec- 
tion was  the  largest.  The  programming  section  averaged  about  six  men; 
the  research  section  was  in  fact  one  man.   Since  both  1050 's  had  been 
too  small  to  support  meaningful  use  of  FORTRAN  or  COBOL  until  recently, 
the  programming  and  operations  sections  were  familiar  only  with  PAL, 
an  assembly-language  system. 

Non-EDP  Personnel;  Peerless  had  a  major  asset  (for  building  an 
LP-based  planning  system)  in  its  Process  Design  group.   The  group  varied 
in  size  (averaging  around  six)  and  had  responsibility  for  a  wide  range 
of  analytic  activity  (e.g.  calculating  yields,  analyzing  hog  purchase, 
"etc.).  Also,  this  group  regularly  ran  LP-based  sausage  formulations. 
The  group  had  some  knowledge  of  LP  and  access  to  the  information  needed 
for  constructing  the  LP  model,  but  they  were  organizationally  independ- 
ent of  and  isolated  from  the  provisioners,  ^^ich  reduced  their  effect- 
iveness somewhat. 
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Hov  Limited  Resources  Affect  System  Desisn 

Preliminary  estimates  indicated  that  the  LP  model  underlying  the 
planning  model  would  need  about  1500  equality  rows  and/or  upper 
bounds.  While  there  existed  a  small-capacity  LP  package  for  the  1050 's, 
there  was  no  real  hope  for  installing  the  LP  on  one  of  Peerless'  ma- 
chines. We  had  to  look  elsewhere  for  a  machine  to  run  the  model. 

We  planned  initially  to  use  a  UNIVAC  1107  located  in  St.  Paul, 
Minnesota,  150  miles  from  Cedarton,  Data  transmission  at  Peerless  was 
to  be  handled  by  a  high-speed  paper-tape  system,  or  by  a  communication 
subsystem  attached  to  one  of  the  1050 's.  Assiiming  five-level  code, 
1500  columns,  1500  rows  and/or  bounds,  and  an  average  of  200  characters 
of  Inforsiation  about  each  structural  variable  and  bound  row,  an  ordin- 
ary 2400  baud  telephone  line  would  have  permitted  transmission  of 
output  back  to  Peerless  in  less  than  half  an  hour.  We  found,  however, 
that  there  would  be  a  large  expense  associated  with  such  a  communica- 
tion subsystem  and  that  the  high-speed  paper  tape  device  had  been  re- 
moved. The  alternative  was  a  teletype  35  ASR  for  paper-tape  punching; 
this  would  require  about  ten  hours  to  punch  all  the  output.   Transmis- 
sion of  iiqjut  to  St.  Paul  was  estimated  to  require  another  two  hours. 

It  would  not  have  been  feasible  to  accept  twelve  hours  of  trans- 
mission time  per  run,  especially  since  the  probability  of  having  to 
make  at  least  two  attempts  per  successful  run  seemed  high.   One  possi- 
ble solution  was  to  transmit  to  St.  Paul  only  changes  in  input  data 
and  to  transmit  back  from  St.  Paul  only  changes  in  solution  values,  after 
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stripping  out  all  excess  blanks  and  other  unnecessary  characters. 
Preliminary  estimates  (and  later  experience  with  the  actual  LP  model 
as  tested  elsewhere)  indicated  that  this  would  reduce  transmission 
time  to  about  one  and  one-half  hours.   This  was  thought  acceptable. 

In  order  to  achieve  this  reduction  in  transmission  time  it  would 
have  been  necessary  to  maintain  data  files  and  file  maintenance  pro- 
grams at  St,  Paul  as  well  as  at  Cedarton.   Starting  with  a  new  input 
file  at  Cedarton^  we  would  have  gone  through  the  following  procedure: 
At  Cedarton; 

Using  Old  Input  File  and  New  Input  File,  produce  paper  tape 
containing  changes 

Transmit  change  tape  to  St.  Paul 

At  St.  Paul; 

^         Receive  change  tape 

Using  change  tape  and  Old  Input  File,  create  New  Input  File 

Run  LP  with  New  Input  File  Producing  New  Output  File 

Using  New  Output  File  and  Old  Output  File,  create  paper  tape 
containing  changes. 

Transmit  change  tape  to  Cedarton 

Rename  New  files  as  Old 

At  Cedarton; 

Receive  change  tape 

Using  change  tape  and  Old  Output  File,  produce  New  Output  File 

Rename  New  Tapes  as  Old. 
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As  can  be  seen,  this  procedure  would  have  required  nearly  coii5>lete 
duplication  of  both  information  and  programs  in  two  widely  separated 
locations.  On  reflection,  therefore,  it  seemed  unattractive.  An  alter- 
native was  carrying  tapes  to  and  from  St.  Paul  by  air.   The  time  in- 
volved for  this  method  would  have  been  about  the  samp  as  for  teletype 
transmission,  but,  if  necessary,  someone  could  have  accompanied  the 
tape,  thus  allowing  a  number  of  possible  tries  at  solution  before  re- 
turning.  Planning  thus  began  for  a  system  with  basic  turn-around  time 
of  one  full  day. 

Issues  Raised  by  Long  Turn-Around  Times 

The  expectec*  one-day  turn-around  time  for  the  system  imposed  an 
absolute  requirement  that  a  plan  drawn  by  the  system  be  usable  for 
tvo  days  after  data  input,  if  re-planning  was  to  occur  every  day. 
Prices,  however,  can  change  hourly,  and  this  caused  some  fear  that  no 
plan  drawn  could  ever  be  implemented.  Much  hangs  on  our  use  of  the 
vord  "usable."  Under  the  present  normal  system,  plans  were  drawn  once 
a  week  and  real-time  modifications  made  as  the  week  progressed.   Cer- 
tainly, a  system  which  could  draw  a  "better"  plan  once  a  week  would  be 
"usable"  in  the  context  of  real-time  modifications. 

This  thinking  led  to  a  proposed  method  of  operation:   the  LP  would 
be  run  on  a  basic  weekly  cycle.   The  provisioners  would  meet  over  the 
output  to  make  their  normal  plan  for  the  coming  week.  During  the  week 
of  operation,  the  provisioners  would  have  available  the  by-product  in- 
formation from  the  LP  as  well  as  a  supplementary  report  detailing  plans 
and  achievements,  and  flagging  major  deviations.   The  normal  real-time 
adjustments  would  be  made,  but,  at  some  level  of  discomfort,  the  entire 
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planning  process  could  be  Invoked  with  one-day  lead  time,  regardless 
of  whether  it  were  early  or  late  in  the  week. 

Previously,  we  assumed  that  changeover  costs  were  absorbed  in 
the  cost  of  planning.   In  fact,  we  were  unable  to  determine  changeover 
costs  for  the  Peerless  manufacturing  operation.  We  were  assured  that 
in  many  cases  these  were  minimal,  since  machines  typically  had  to  be 
cleaned  and  set-up  each  morning  anyway.  Clearly,  however,  a  large 
change  in  the  rate  of  hog-killing  would  cause  costs  to  be  incurred. 
We  decided  to  leave  this  to  the  user  of  the  system  by  giving  him  the 
approximate  cost  of  not  following  a  new  plan.  He  could  then  decide 
vhether  or  not  to  actually  change  production  costs  involved.   This 
mmber  also  provides  feedback  to  the  user  as  to  how  necessary  re- 
planning  really  was. 

We  expected  that  initial  use  of  the  planning  system  would  show 
re-planning  much  more  often  than  once  a  week,  but  that  the  proportion 
of  times  when  new  plans  were  -trnplemented  on  the  production  floor  would 
be  relatively  low.   We  also  expected  that,  as  users  became  more  famil- 
iar with  the  system,  their  demands  for  re-planning  would  fall,  while 
the  proportion  of  implementation  would  rise.   These  expectations  were 
based  on  the  belief  that  humans  are  efficient  pattern-recognizers  and 
on  the  belief  that  profound  changes  in  the  structure  of  a  solution 
would  have  relatively  small  effects  on  the  value  of  the  solution. 
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Design  and  Ck)nstruction  of  the  LP  Support  System 

The  LP  support  system  was  designed  to  give  the  users  as  many 
features  of  the  "ideal"  system  as  could  be  achieved  on  a  small  tape- 
oriented  coo^uter^  given  the  necessity  of  carrying  tapes  back  and 
forth  between  the  "home"  coiq>uter  and  the  large  machine  required  for 
the  LP.  Three  major  features  had  to  be  sacrificed  entirely^  though 
partial  compensation  was  possible.   (Other  features^  recognized  as 
worthy  but  not  absolutely  essential  for  operation,  were  deferred  and, 
as  a  result,  never  implemented.)  The  three  lost  features  were: 

1)  On-line  editing  and  modification  of  coefficients; 

2)  On-line  calls  for  special  reports;  and 

3)  Monitoring  by  partial  solution. 

In  our  view,  the  most  serious  loss  was  the  third.  All  question 
as  to  whether  or  not  a  solution  remains  optimal  in  the  face  of  multi- 
ple price  changes  becomes  unimportant  if  the  LP  code  itself  is  avail- 
able for  monitoring.   The  process  is  sin^jlicity  itself:  using  the  old 
basis  inverse  and  the  new  set  of  prices,  perform  one  matrix  multipli- 
cation to  determine  the  new  set  of  reduced  costs.   If  these  are  all 
non-positive  (except  for  variables  at  upper  bound  which  must  be  non- 
negative)  then  the  solution  remains  optimal.   Since  the  basis  inverse 
really  specifies  a  set  of  row  transformations  sufficient  to  change  the 
Initial  simplex  tableau  into  the  final  (optimal)  tableau,  it  matters 
very  little  whether  the  inverse  is  kept  in  terms  of  the  actual  inverse 
(around  400,000  nuznbers),  product  form  (usually  many  fewer  numbers), 
or  just  as  a  list  of  variables  and  their  solution  status  together  with 
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The  original  tableau  (least  of  all  because  of  the  sparseness  of  the 
original  matrix).  In  any  of  these  cases,  the  tisie  required  to  re- 
calculate the  reduced  costs  in  on  the  order  of  a  minute  or  two  on  the 
class  of  machine  needed  to  support  the  LP  code  itself.  However,  on 
a  UKIVAC  1050  with  24K  core  and  no  random-access  mass  storage,  this 
task  becomes  huge. 

In  this  section  we  describe  the  design  of  the  system  in  broad 
-terns.   It  is  appropriate  to  begin  with  the  most  iiiq>ortant  artifact 
of  the  system. 

The  LP  Master  File;  The  LP  Master  File  is  a  single  reel  of  tape 

containing  all  information  required  to  run  and/or  interpret  two  differ- 

-ent  versions  of  the  model.  We  will  call  these  two  models  the  current 

"or  A-model  and  the  new  or  B-model.  Both  models  are  on  the  same  tape 

for  reasons  of  single  data-handling  ease.  The  file  is  in  column  order, 

and  for  each  column  contains: 

Column  Coefficients  for  A-model 

Alphabetic  description  of  column 

Solution  information  for  this  coltmin  of  A-model 

Colimrn  coefficients  for  B-model 

Alphabetic  description  of  column 

Solution  information  for  this  colimm  of  B-model 

Let  us  consider  the  use  of  the  Master  File  throughout  the  planning 
cycle.  Suppose  we  have  just  implemented  a  plan  based  on  the  most  re- 
cent solution  of  the  LP.  At  this  point  (take  it  on  faith)  the  A-model 
and  the  B-model  are  identical.  We  now  consider  functions  of  the 


See  the  Appendix  for  san^les  of  many  system  artifacts. 
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support  system,  given  this  initial  situation. 

Modify  Prices  and/or  Bounds;   A  new  set  of  prices  and  bounds 
are  prepared  and  punched  on  cards.   These  cards  are  used  to  update 
the  coefficients  and  solution  information  corresponding  to  the  most 
recent  run  of  the  LP,  while  the  B-sector  contains  coefficients  for 
the  next  run  of  the  LP.  B-model  solution  information  is  now  meaning- 
less. 

Modify  Model  Structure;   The  same  as  above,  except  that  coeffi- 
cients other  than  prices  and  bounds  may  be  changed,  and  whole  columns 
and/or  rows  may  be  added  or  deleted.   These  two  functions,  which  are 
handled  by  the  same  program,  are  the  equivalent  of  MODSTRUCTURE  (and 
EDSTATUS) . 

Monitor  Changes;   A  report  is  drawn  showing  the  net  difference 

between  the  coefficients  in  the  A-model  and  the  B-model.   That  is, 

every  coefficient  which  is  either; 

Different  in  B  from  value  in  A;  or 
Present  in  B  but  not  in  A;  or 
Ibt  present  in  B  but  present  in  A 

is  written  out  in  a  report  giving  before-and-af ter  values. 

Monitor  Prices;   Every  column  whose  B-price  is  outside  its  C-range 
as  defined  by  the  A-solution  is  noted  on  a  report,  together  with  full 
Information  from  both  models. 

List  Model;   The  complete  B-model  is  listed  in  column  and/or 
row  order. 
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Draw  Input  Tape;  The  B-model  is  transformed  into  a  tape  suitable 
for  use  as  Input  to  the  LP  package. 

Optimize;  Not  a  part  of  the  support  system,  this  step  consists 
of  carrying  the  LP  input  tape  as  prepared  above^  the  optimal  basis  (on 
cards)  from  the  last  run, and  any  changes  deemed  necessary  by  the  user, 
to  the  machine  on  which  the  LP  code  is  resident.   The  output  is  a  new 
-optimal  basis  deck,  an  LP  output  tape,  and  printed  reports. 

TTpdate  B-Solution;   The  LP  output  tape  is  used  to  update  the 
B-solution  in  the  Master  File.  The  Master  File  now  contains  the  most 
recently  implemented  model  (A-model)  and  the  most  recently  unimplemented 
nodel  (B-model).  Solution  Information  for  each  model  corresponds  to 
its  coefficient  information  and  includes  the  quantities  called  for  pre- 
viously. 

Report;  The  entire  B-solution,  together  with  alphabetic  descrip- 
tions, is  written  in  a  report  suitable  for  use  by  the  provisioners  and 
product  managers. 

Report  Solution  Changes;   The  entire  Master  File  is  scanned,  and 

whenever  the  B-solution  differs  in  any  way  from  the  A-solution,  both 

are  written  out.   By  means  of  this  function,  the  user  can  judge  how 

profound  the  changes  in  solution  actually  were.   In  addition,  this 

report  contains  the  three  objective  function  values  mentioned  above, 

-namely: 

A-model  objective  function; 

B-model  Abjective  function;  and 

A-B  objective  function  (A-quantities  at  B-prices) 
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Accept  Solution:  This  routine  (actually  the  same  as  the  Report 
Solution  Changes  routine)  produces  a  new  Master  File  whose  A-section 
has  been  replaced  by  the  B-section;  that  is^  the  B-model  is  declared 
to  be  current. 

Dung)  Model;  The  entire  B-section,  including  coefficients,  descrip- 
tions, and  solution  information  is  dumped  in  a  single  report  to  the 
major  user.  This  givea  him  a  superior  ability  to  trace  out  any  unusual 
result.  In  fact,  this  is  the  same  routine  which  is  used  to  create  a 
listing  of  the  model  in  column  order.  The  difference  is  in  the  timing; 
the  column  list  comes  before  the  solution,  the  dump  afterwards . 

This  complefs  the  description  of  the  main  parts  of  the  LP  support 
system.  In  addition,  there  are  two  routines  designed  to  prevent  errors. 

Monitor  Inconsistencies;  Every  alphabetic  description  begins  with 
a  single  character  giving  the  class  of  variable  (e.g.  B  for  buy,  S  for 
j^ell,  A  for  allocate,  etc.).  This  routine  checks  every  column  descrip- 
tion against  its  new  (B-model)  price  and  flags  inconsistencies  such  as 
a  positive  price  for  a  bought  quantity. 

Manipulate  Prices;  Designed  to  prevent  errors  by  reducing  the 
task  of  data  iiq>ut,  this  routine  accepts  a  table  of  relationships  be- 
tween one  master  price  (say  the  Chicago  tcarket  for  a  primal)  and  many 
dependent  prices  (cost  of  purchase,  return  from  sale  of  the  same  primal 
at  Cedarton) .   It  then  accepts  master  prices  and  punches  change  cards 
to  correspond. 
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Implementation  of  Variable  Planning  Interval  Through  Hxjman 
Decisions:  There  are  obviously  two  decision  points  in  the  replanning 
process.   The  first  comes  in  deciding  whether  or  not  to  re-plan.   This 
decision  is  made  by  the  provisioners  using  certain  system  functions 
already  described.   Remember  that  the  B-model  has  the  cumulative  changes 
in  coefficients  since  the  A-model  was  run.   At  any  time^  the  provision- 
ers can  invoke  the  Monitor  Prices  routine  to  get  a  list  of  all  columns 
vhose  prices  fall  outside  their  C-ranges.   The  provisioners  must  still 
decide  whether  or  not  to  re-plan.   They  will  be  aided  by  the  report 
from  the  Nsnitor  Changes  routine.  For  instance^  if  there  are  a  lai  <^t= 
number  of  columns  appearing  on  the  Monitor  Prices  report,  but  the 
Monitor  Changes  report  shows  them  all  to  be  proportional  changes  in 
the  prices  of  various  versions  of  one  single  primal,  the  odds  are  good 
Chat  the  current  solution  in  fact  remains  optimal. 

It  is  also  true  that,  at  any  time,  the  provisioners  can  invoke 
the  Draw  Ii^ut  Tape  routine  to  initiate  the  remote  procedure  for  ob- 
taining an  LP  solution.   Having  done  so,  and  having  obtained  an  LP 
Output  Tape  and  run  Update  B-solution,  the  provisioner  is  forced  with 
deciding  whether  or  not  to  accept  (iii5)lement)  the  new  solution.   To 
aid  in  this  procedure,  he  has  three  documents:   the  LP  report  as  pro- 
duced by  the  LP  code  itself;  the  LP  report  produced  by  the  Report 
routine;  and  the  Change  report  produced  by  the  Report  Solution  Changes 
routine.   He  must  judge  whether  the  return  from  changeover  to  the  new 
plan  Justifies  its  costs.   These  reports,  and  (later  on)  his  experi- 
ence in  previous  decisions  of  the  same  sort,  should  allow  him  to  make 
good  decisions  on  the  question  of  acceptance. 
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Construction  of  the  System;   The  system  was  constructed  as  a  set 
of  a»dules^  some  of  which  vere  progranmed  by  UNIVAC  personnel,  the 
rest  by  Peerless.   (See  Figure  3.)  The  major  modules  were: 

1)  Create  sorted  change  tape.   Cards  are  accepted  in  a  variety 
of  formats,  converted  to  a  single  consistent  format,  and  sorted  into 
column- row  order  for  updating  the  Master  File.   One  problem  arose  here 
—  the  sort,  a  standard  merge  procedure,  would  not  necessarily  preserve 
the  order  of  tied  entries.  As  a  result,  no  duplicate  column-row 
coDd>lnation  could  be  tolerated  in  a  single  batch  of  change  cards. 

This  meant  that  change  cards  from  two  separate  days  (or,  for  that  mat- 
ter, hours)  could  not  be  batched  together.   A  normal  procedure  for  pull- 
ing duplicates  was  instituted  teo;>orarlly,  but  the  long-term  solution 
was  to  append  the  serial  position  of  each  card  in  a  batch  to  the  sort 
key  before  sorting. 

2)  Update  B-model.   A  sorted  change  tape  is  passed  agalnt  a 
Master  File,  and  a  new  Master  File  created  whose  B-model  embodies  the 
changes  specified.   As  above,  no  duplicate  changes  were  tolerated  in 
the  first  version;  later  versions  were  to  ignore  all  but  the  last  such 
duplicate. 

3)  Extract  Extended  Master  File.   The  Extended  Master  File, 
consisting  of  complete  B-model  information  in  an  easy-to-process  form, 
is  extracted  from  the  Master  File.   This  is  used  by  several  other 
modules  (see  below),  and,  as  a  bonus,  is  in  the  same  format  as  a 
sorted  change  tape,  so  that  it  can  be  used  to  create  a  whole  new  B- 
nodel  if  necessary. 
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Figure  3  (continued) 
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Figure  3  (continued) 
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4)  Produce  LP  Input  File.   The  Extended  Master  File  is  passed  and 
a  tape  acceptable  to  the  remote  LP  code  is  written.   This  program  was 
to  exist  in  three  versions: 

a)  Produce  full  input  tape  for  1107  code.  Each  coefficient 
becomes  a  card  image  in  1107  format.  Each  column  bound  becomes 

a  new  row  and  a  coefficient  card  image  and  a  right-hand-side 
element  card  image. 

b)  Produce  change  tape  for  1107  code.  As  above,  but,  by 
^comparing  against  Master  File  A-model,  program  suppresses  card 
Images  which  have  not  changed  since  last  run. 

c)  Produce  full  input  tape  for  360  code.   As  a)  above, 
but  bounds  do  not  become  new  rows;  rather,  they  are  held  in  one 
special  row  acceptable  as  Input  to  the  360  LP  code. 

5)  Coiq>are  coefficients.  A  comparison  is  made  between  the 
Haster  File  A-model  and  the  Extended  Master  File  (drawn,  of  course, 
from  the  B-model) .  Depending  on  the  setting  of  a  switch,  this  com- 
-parison  results  in  either; 

a)  Report  of  changed  coefficients;  or 

b)  Report  of  prices  outside  their  C-ranges. 

6)  Check  Inconsistencies.   Performs  the  function  called  "Moni- 
tor Inconsistencies"  above,  using  the  Extended  Master  File  as  input. 

7)  Produce  row  list.   The  Extended  Master  File  is  sorted  in 
row-column  order  and  printed. 
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8)  Dump  Master  File.   The  B-model  of  the  Master  File  is  printed 
verbatim.  This  is  used  both  as  a  colisnn  listing  of  the  model  and  as 
a  Biodel  dump  after  updating. 

9)  Update  B-solution  and  report.   The  LP  Output  Tape  is  scanned 
and  information  collected  by  column.   This  collected  information  is 
then  inserted  into  the  B-solution  area  of  the  Master  File.  Eacli 
updated  B-solution  line  is  printed.   Because  of  the  format  of  the 
Master  File,  these  printed  lines  become  the  Peerless  LP  report.  There 
were  to  be  two  versions  of  this  routine: 

a)  Process  1107  output.   This  version  would  have  to  asso- 
ciate four  pieces  of  information  with  each  column: 

1)  Column  solution  information 

li)  Row  solution  information  for  special  rows  created 
as  bounds 

ill)   Post-opt imality  information  by  column 

iv)  As  Hi)  for  rows. 

b)  Process  360  output.   As  a)  but  types  11)  and  iv)  not 
required  because  of  use  of  bounded  variable  algorithm. 

10)  Print  Changes.   Described  above  as  "Print  Solution  Change 
Report." 

In  addition  to  the  major  modules  described  above,  several  others 
had  been  designed  and  partially  programmed  by  December,  1967.   These 
were: 

11)  Extract  price  information  from  PYRAMIDS, 
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12)  Produce  control  report  from  PYRAMIDS. 

13)  Manipulate  prices. 

14)  Produce  special  reports  (table-driven). 

Testing  of  the  LP  Support  System  and  Parallel  Operation  of 
the  Planning  System 

Testing  of  the  LP  support  system  and  first  use  of  the  planning 
system  were  carried  out  together,  because  it  was  felt  that  there  could 
be  no  better  test  of  the  support  system  than  coping  with  an  actual 
model  in  a  closely  simulated  planning  context.  Accordingly,  testiv 
of  the  whole  system  began,  even  though  it  was  far  from  con^jlete. 

r 

At  the  outset  we  had  one  stroke  of  good  luck.  A  360/50  with 
138K  bytes  of  core  was  found  in  Cedarton  itself.  The  company  leasing 
.the  machine  (call  it  the  Nonpareil  Con^any)  had  already  brought  the 
360  LP  code,  MPS/360,  to  fully  usable  status  and  was  willing  to  let 
Peerless  use  several  hours  per  month  on  very  reasonable  terms.   The 
availability  of  MPS/360  significantly  reduced  the  programming  required 
for  many  of  the  modules  described  previously.   More  important,  the 
"remote"  machine  was  now  only  20  minute's  drive  from  Peerless.   The 
tape-carrying  procedure  required  by  the  system  began  to  look  more  and 
more  feasible. 

One  complication  arose.   The  Peerless  equipment  used  90-column 
cards  and  7-track  tapes,  while  the  Nonpareil  equipment  used  80-col\ann 
cards  and  9-track  tapes.   This  problem  was  resolved  when  Peerless  agreed 
to  subsidize  Noi^areil  to  the  extent  of  one  7-track  tape  unit,  and, 
in  addition,  installed  one  IBM  Keypunch  on  the  Peerless  premises. 
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Another  minor  problem  was  the  difference  in  character  codes  be- 
Cveen  the  UNIVAC  and  IBM  equipment.   This  was  handled  by  substituting 
«  non-standard  conversion  table  for  the  normal  one  built  into  UKIVAC 
software.   In  shorty  data  transmission  problems  were  solved  reasonably 
quickly. 

Operating  procedure  at  Nonpareil:  The  operating  procedure  at 
Bonpareil  became  a  well-established  routine: 

1)  Mount  LP  Input  File  on  7-track  drive. 

2)  Run  MPS  CONVERT  routine  to  convert  LP  problem  to 
Internal  format  on  a  new  tape  file  PROBFILE. 

3)  Run  MDDIFY  routine  to  enter  any  changes  to  model 
{usually  errors  detected  and  punched  after  the 
preparation  of  the  LP  Input  File) . 

A)  Run  SETUP  routine  to  prepare  to  solve. 

5)  Run  INSERT  routine  to  insert  optimal  basis  from 
last  run. 

6)  Run  PRIMAL  routine  to  solve. 

7)  Run  SOLUTION  routine  to  write  solution  information 
on  LP  Output  Tape. 

8a)   (If  infeasible)  Run  TRACE  routine  for  diagnostic 
information;  or 

8b)   (If  unbounded)  Skip  to  9;  or 

8c)   (If  feasible-optimal)  Run  RANGE  routine  for  C-ranges,  etc. 

9)  Run  COBOL  program  (written  for  the  purpose)  to  print  LP 
Output  Tape  and  copy  the  relevant  subset  onto  the  7-track 
drive  (where  a  blank  tape  should  have  been  mounted  during 
PRIMAL)  for  carrying  back  to  Peerless. 

10)  Examine  output.   If  infeasible,  unbounded,  or  unreasonable, 
correct  errors  and  return  to  step  3.   Otherwise,  go  home. 
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It  should  be  noted  that  all  the  above  steps  (except  for  numbers 
1  and  10)  are  performed  automatically  via  the  MPS/360  control  language 
and  the  OS/360  Job  Control  Language. 

In  early  runs,  the  whole  procedure  required  an  average  of  three 
or  more  tries  on  the  machine,  2  hours  of  360/50  time,  and  10  hours 
of  effort  by  each  of  two  or  three  men.  By  December,  1967,  error  de- 
•tection  and  correction  and  general  knowledge  of  the  model  had  progressed 
so  that  a  tj^pical  Nonpareil  run  required  one  or  two  tries,  a  total  of 
45  minutes  of  computer  time,  and  perhaps  6  man-hours  of  effort. 

The  timing  figures  given  are  for  the  con^jlete  model  which  was 
In  flux  throughout  the  testing  period,  but  which  averaged  700  rows  and 
2100  columns.  Some  of  the  problems  encountered  in  debugging  the  whole 
system  were: 

1)  Infeasibility:  because  of  the  model  structure,  infeasi- 
blllty  was  usually  the  result  of  errors  in  the  change  cards.  Because 
of  the  structure  of  MPS/360,  such  errors  were  easy  to  trace.  But 
each  occurrence  forced  additional  delay. 

2)  Unbounded  Solutions:   change  card  errors  were  again  respon- 
sible for  most  unbounded  solutions.   However,  MPS  (or  at  least  the 
version  we  used)  had  no  facility  for  revealing  which  variable  was  being 
brought  into  solution  at  the  time  unboundedness  was  detected.   Our 

.first  cut  at  ameliorating  this  problem  was  to  modify  the  "Prepare  LP 
Input  Tape"  procedure  to  supply  a  large  upper  bound  for  all  variables 
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without  natural  upper  bounds.  Then  any  unbounded  solutions  were  easily 
traced  after  optimality.   Our  second  approach  also  involved  a  modifi- 
cation to  "Prepare  LP  liiput   Tape."  MPS  permits  the  definition  of  a 
new  row  as  the  linear  combination  of  any  two  other  rows.  We  defined 
such  a  row  to  be  identical  to  the  objective  function,  but  to  be  a  less- 
than  constraint  with  a  right-hand-side  value  roughly  four  times  the 
largest  expected  objective  function  value.  Thus,  when  an  unbounded 
solution  occurred,  the  next  variable  entered  into  solution  raised  the 
extra  row  to  its  maximum  value  and,  there  being  no  further  way  to  f 
crease  the  objective  function,  the  simplex  procedure  terminated.  The 
trace  of  iterations  leading  to  solution  would  then  have,  as  its  last 
entry,  the  identification  of  the  unbounded  variable.  The  advantage  of 
this  method  over  the  first  is  that  it  would  typically  waste  less  time. 
That  is,  the  detection  of  an  unbounded  solution  terminated  the  simplex 
procedure. 

3)  Huge  volume  of  data  input:   Our  preliminary  estimates  were 
that,  on  average,  200  to  500  prices  and  bounds  would  change  between 
runs.   In  fact,  running  on  a  weekly  cycle  (with  the  option  of  ruiming 
sooner  if  required),  we  found  that  700  to  1200  numbers  had  to  be  input 
for  each  run.  The  major  cause  of  excess  data  input  was  that  the  product 
managers  found  it  easier  (or  at  least  safer)  to  send  in,  as^  changes. 
every  price  and  bound  under  their  control,  whether  actually  changed  or 
not.   This  put  a  heavy  load  on  the  time  and  patience  of  everyone  con- 
cerned in  the  input  process,  not  least  the  product  managers  themselves. 
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The  long-term  solution^  of  course^  was  to  use  the  PYRAMIDS  £lle  as  a 
data  source,  thus  eliminating  almost  all  manual  input.  In  the  short 
run,  however,  we  designed  a  set  of  couputer-prepared  input  forms,  so 
that  the  product  managers  could  see  what  the  old  value  of  each  price 
or  bound  was  as  they  were  writing  in  new  values.  This  was  expected  to 
rednce  changes  to  the  originally  estimated  level,  but  there  were 
enough  technical  problems  in  producing  such  input  forms  so  that  this 
fe«t\jre  was  never  fully  iiq>lemented. 

4)  Consistently  incorrect  coefficients:   System  testing  uncc   ed 
vhat  was  apparently  a  long-standing  disagreement  between  the  "official" 
cut-out  yields  and  the  yields  used  by  provisioning  to  predict  primal 
4>roductlon.  The  "official"  yields  were  re-worked  and  entered  into  the 
model  four  times,  but  the  model  was  never  able  to  be  even  qualitatively 
«8  accurate  as  the  provisioners'  estimates.  There  was  a  carefully  con- 
trolled test  in  which  the  "official"  yields  operated  upon  actual  hog 
kill  experience  for  a  week,  and  even  then  there  was  only  fair  agreement 
between  actual  production  and  model  predictions.   The  "official"  yields 
were  being  reqorked  for  the  fifth  time  when  work  on  the  project  was 
suspended. 

There  were  many  other  problems  —  human,  hardware,  and  software  -- 
but  the  four  above  were  the  major  obstacles.  There  were  also  several 
benefits,  but  the  outstanding  gain  came  from  the  involvement  of  Peerless 
-personnel  in  the  model-building  and -error  -tracing  processes.   The 
Process  Design  group  was  the  greatest  beneficiary,  but,  as  each  new  run 
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vas  examined  and  criticized^  even  the  provlsloners  and  product 
■anagers  gained  Insight  into  the  hog-to-flnal-product  process.   There 
is  some  evidence  that  this  effect^  at  least,  will  be  long-term  help  to 
Peerless. 

The  End  of  the  Project 

Financial  difficulties  forced  Peerless  to  cancel  all  projects 
"not  now  fully  implemented"  in  December,  1967.  The  LP-based  plan- 
nlng  system  fell  into  this  category  and  was  accordingly  "suspended  in- 
definitely." But,  as  always,  the  classification  of  the  planning  s. 
tem  as  "not  now  fully  lin>lemented"  was  a  human  decision  —  in  this  case, 
a  decision  of  the  Chief  Provisioner.  His  stated  reason  was  that, 
given  Peerless'  very  tight  cash  position,  he  did  not  have  enough  man- 
euvering room  to  exploit  the  LP  recommendations,  even  if  he  could  rely 
on  them  —  and  the  fact  that  the  very  Important  yield  coefficients  were 
in  their  fifth  re-work  was  evidence  enough  that  he  could  not  rely  on 
the  LP. 

There  were  several  contributing  factors  of  which  two  should  be 
cited: 

First,  the  long  turn-around,  high  error  rate,  and  inability  to  get 
good  predictions  of  primal  production  (all  of  which  we  en^hasize,  were 
improving  rapidly  with  time)  had  allowed  the  provlsloners  to  avoid  con- 
fronting the  question  of  just  how  much  help  the  system'could  be  as  a 
planning  aid.  They  were  therefore  uncommitted. 
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Second,  parallel  operation  of  two  systems  Is  a  meaningless  exer- 
cise when  the  users  have  never  really  had  enough  time  to  keep  the 
old  system  running  smoothly.   This  was  very  nearly  the  case  at  Peerless. 
The  additional  time  required  to  run  the  new  system  in  parallel  was  a 
far  more  burdensome  cost  than  the  additional  money. 

Indeed,  the  only  way  that  all  the  problems  could  have  been  solved 
would  have  been  for  the  provisioners  to  take  responsibility  for  the 
accuracy  of  data  input  and  the  smooth  operation  of  the  support  system. 
However,  there  is  a  clear  tendency  for  people  to  prefer  responsibi'^.^y 
for  an  overall  (human-generated)  plan  to  responsibility  for  the  num- 
bers on  which  a  (machine-generated)  plan  is  based.   Some  of  the  rea- 
sons are  abvious.  First,  human  plans  have  the  characteristic  that  the 
consequences  of  errors  tend  to  be  proportional  to  the  magnitude  of  mis- 
Cakes,  while  a  machine-generated  plan  has  the  potential  for  a  very 
small  error  (in  input  data)  to  produce  profound  errors  in  the  plan. 
Second,  in  this  particular  coii;>lex  planning  scheme,  it  is  hard  to  pre- 
dict what  effect  on  the  plan  will  be  caused  by  a  relatively  minor 
decision  about  prices,  bounds,  and  the  like.   It  may  be  that  this  plan- 
ning system  gave  the  provisioners  too  much  responsibility. 

Shortly  after  the  planning  system  was  suspended,  the  provisioners 
evolved  a  scheme  which  has  some  of  the  potential  of  the  LP  system  and 
many  fewer  problems.   Starting  with  each  primal,  manual  calculations 
are  made  of  the  potential  profit  for  each  possible  way  of  allocating 
that  primal  to  production.   These  profit  figures  are  then  used  in  mak- 
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ing  allocation  decisions.   Such  a  scheme^  while  It  does  not  take  ac- 
count of  interactions  and  Is  therefore  surely  suboptlmal^  will  be,  we 
hope,  at  least  livable,  and  certainly  better  than  what  existed  before 
the  LP-based  planning  system  was  initiated. 

In  Conclusion 

This  paper  provides  docinnentation  of  the  steps  and  pitfalls  in 
the  design  of  a  system  to  make  LP  a  useful  technique  for  managers 
charged  with  day-to-day  production  scheduling  decisions.  The  "ideal" 
system  is  offered  as  a  model  of  what  such  a  system  can  be.  As  ijo(  -    .• 
ant,  the  actual  system,  while  not  now  in  use,  demonstrates  that  such 
a  system  can  be  constructed  even  when  severe  resource  limitation 
exists. 
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APPENDIX 


Sample  System  Artifacts 


1.     Sample  T)xanp  of  the  B-Sectlon  of  the  LP  Master  File 


CL0525   B '1      Oms 


-1. 


0926 


SB, A   35-UP_0THER   GR_SK  .HAM_BS 27.001 


.8031    1051 


3t. 

* 


CLC526  B  0   0421     -1,        0701 

CL0526  BO   0706 0,1    0707 

CL052b  3  0  "1002      0.0278    1050 
CL0526  B  1   1059     0.0018    1060 


0.1 
0.1 


^S3_.A__2-25-DWiNI._C_CaN_SrSKHM_B5_ 


0.0  86~^ 
0.0071 
132.089 


0702 

0708 

Y05l 

1502 


ID. 


CL0527  B  1   0422     -i;        0926   '    .729«»    1051 
_S3_A_2  25-pP  OTHER  GrSKOHAM  BS___24v855 . 


CL0529  B'O 
Cl'0529  B  1 
S3  A  B-12  C" 


0401     -I,       0701   '  1, 
1052  _  0.131 1053     0.0'»2 

CAN  GR  Sk  ham    LL 


_Cl0530  B  0 
CL0530"  B'  0 
CL0530  3  1 


0402 
1050 
1060 


-1. 


0.066 
0,0071 

5B_A_1 2-l4_C_  C  A  N_6g_SK_:H  AM_ 


LL 


_0701__ 
1051 
1502  99999. 


_  _^160a. 
0.089 


CL0531  B  0 
CL0551_B^0 
CL0531  3  1 


0403     -1. 

1051    o;o89_ 

1502  99999. 


0703 
1052 


0.54 
0.131 


SB  A  14-16S  C  CAN  qR   SK  HAM  LL 


CL0532  B  "0   0405     -1.' 
CL0532  B  0   1050  '    0,066 
_CU0532  B  1  _1060  _1__0.0071_ 
SB  A  16-lBS  C  CAN  G-R  »K  HAM  BS 


0704     0.22 
105l   '   0.089 

1502  99999; 

531*362 


1001 
_105'»  _ 
.08642- 


i0702 
1052 


.03193- 


0704 
1053 


•03555- 


0705 
1052 


1 


,2 ^Cl;0533_3_0 0407 rl ._ 0706   -   0.66  _ 

CL0533  3  0   1051     0.089    1052     O.lSX 
CL0533  B  1 


_     _     1502  99999, 

saLA_i8-20s_c  ^  can_gR_sk  _HAM_Lj.. 


CL0534  B  0   0409  '   -1.'       0707     0.43 

CL0534  B  0__l050__ 0,066  l05l      0.089 

CL0534  3  1   1060      0.0071    1502  99999. 
SB  A  20-22S  C  CAN  gR  5k  HAM  BS    541.004 


CL0535  B  0   0411     -1.        0709       W700 
CL0555  B  0   1051     O.O89    lo52     0.131 

CL0535  3  1   1502  99999. 

SB  A  22-24  C  CAN  GR  SK  HAM   BS    74.2'80 


_0707 
1053" 


.00856- 

0708 
1052 


0710 
1053 


CL0536  B  0 
CL053b  3  10 
CL0556  3  1 


0401  __  -1;    0723 0.1_ 

1052     0.1't78   1053     O.O^Sf 
1502  99999. 


3b'  A  Brl2  HT.  CAN.  GR.  SK_.HAM__  LL  . 


1001 
1054 


.4l'»92- 


3>_ 


::. 


Cl'0537  B  0   0402    -1.       0723     0.25 

Cl05j7  3  0   1002__1   0.0287_  105o _: 0^066  _ 

CL0557  B  1   1059     0.0016    1060     0.0064 
S3  A  12-14  HT  CAN  gR  Sk  HAM  BS    67.364 


CL0538  B  0   0403 


-1. 


0726 


0.2 


072f 

1051_ 

l"06*^ 


0727 


,0798    1052       .1121  [  1502  99999.        3301 
. 01000-   CL0522    LL      .02494   CL0352    LL 


•  Ob/ 


•  100 
0.1 


0703 
0709 
1052" 


0.139 
99999. 
_, •  07219-C  L0323 


0.1 

Oj^l     _ 
"0.132 

UL 


0704 

0710_ 

•1053 

INFINITY 


0.1 

o.oer 


0705 
1001 
1054' 

NONE 


0.1 

0.0026 
"0.1005" 


.  .1621    1052      .1025 
•34452-   CL0366    LL 

1502  99999. 
INFINITY 

3301 
NONE 

•  667 

0.0026 
0.0412 

1002 
1059 

0.0378 
0.0018 

1050 
1060 

0.066 
0.0071 

1051 
1502 

0.089 
99999. 

0*61 

1 

•  0703 

ft 

0.23 

1001 
.1054 

0.0026 
0.0412 

1002 
1059 

0.0278 

0.131 

1053 

0.042 

0.0013 

0.46 
0.042 

1001 
1054 

0.0026 
0.0412 

1002 
1059 

0.0278 
0.0018 

1050 
1060 

0.066 
0.0071 

1 

- 

.  I 

0.56 
0.131 


0706 
1053 


0.22 
0.042 


•00066-  CL0742 


0.34 


0.042 


10^54 


1001 
1054 


0.0026 
0.0412 


1002 
1059 


LL 
0.0026    1002 


00163   CL0352 
0.0278 


LL 


0.0412    1059 


0.0018 


1050 

To6o 


0.0278 
0.001& 


0_^066 
"0.0071" 


0.46 
0.131 


0709 
1053 


0.11 
0.042 


1001 
1054 


0.0026 
0.0412 


1002 
1059 


0.0278 
0.0013 


.01138-   CL0311 


UL 


.01084    CL0312 


LL 


0.23 
0.042 

1001      0.0026 
1054      0.0412 

1002 
1059 

0.0278 
0.0018 

1050 
1060 

0.066 
0.0071 

.00551 
0.0023 

3-   CL0360    LL 

1002     0.0287 
1059     0.0016 

1 

•  OOt, 

1050 
1060 

t23   CL031: 
0.066 

3    LL 

1051 
1064 

0.089 

.0514 

0.0064 

.0290 

0.15 
0.089 

0725     0.35 
1052     0.1478 

0726 
1053 

0.25 
0.0464 

1001 
1054 

0.0023 
.0514 

•0290    1502  99999. 

•00401-   CL1951     UL 

700137   CL0352    LL 

0.28 

* 

0728     0.3 

• 

0729 

0.22 

1001 

0.0023 

Sample  Listing  of  Change  Cards  Submitted  to 
"Update  Coefficients" 


CL  R?^tfLRW??^l 


CL82^6RW8860    -1. 
CL82^7RW1500   -99. 

99 

•  CL82^7RW8v»47     1, 
CL8247RWn{60    -1, 

CL8248RW1500    -0. 
CL82A8RW8048     1. 

0728 

CL82A8RWn8.60    -1, 
CL8248RW1501    25, 

CL8249RWlfi00    -0. 
CL8249RW8049     1, 

.1324 

CL8249RW8860    -1, 
CL8249RW1501    24, 

CL8250RW1500   -99, 
CL8250RW8050     1, 

.99 

CL8250RW8860    -1, 
CL8252RW1500   -99, 

99 

CL8252Rl''8052     1, 
CL8252RW8860    -1, 

CL8254RW1500   -99, 
CL6^54RW8054     1, 

,99 

CL8254RW8860    -1. 
CL8256RW1500   -99, 

,99 

CL8256RW6002     1, 
CL8256RW8860    -1, 

.CL8257RW1500   -99, 
CL8257RW6003     1, 

,99 

CL8258RW1500   -99, 
CL8258RWL058     1, 

,99 

£L8258RW8860    -1, 
CL8259RWir.OO   -99. 

,99 

CL8259RWC059     1. 
CL8259RW8860    -1, 

CL8260RW1500    -0. 
CL8260RW8060     1, 

.32 

CL8260RW8860    -1. 
CL8260RW1301     1 

CL8261RW1500   -99 
CL8261RW8860    -1 

.99 

CL8265RW1500    -0 
CL8265RW8061     1 

.37 

CL8265RW8065    -1 
■CL8265RWR^60    -1 

CL8265RW1I01    45 

Sample  Output   of   the  "Monitor   Changes"  Routine 

(Note:      this   sample   taken  prior   to   installation  of 
the   "Monitor  Price"   feature.) 


COEFFICIENT   C.SAN3E   LIST 10-20-67 


COL 

ROW 

MEW 

OLD 

0063 
0063 

1500. 
1503 

-.1555 

NOME 

'  -.1693 
.003  = 

0063 
006(^ 
006t^ 

6020 
1500 
1503 

.0095 
-.1637 

NOME 

.0100 

-.1552 

.0083 

006'4 
0065 

0055 

6020 
1500 
1503 

.0093 
-.1637 

NONE 

.oiin 

-.1552 

.003? 

0055 
0066 
0066 

6020 
1500 
1503 

.0093 
-.1637 

NONE 

.0110 
-.1652 
• .0033 

0055 

5020 

0057 

1500 

0057 

m03 

0067 

6020 

0053 

1500 

0056 

1503 

,0093  .0110 

-.1537  -.1552 

NONE  .OOSB 


.0093  .0110 

-.1637  -.1652 

NOME  .0053 


0068 

..^  0069 

0059 

6020 
1500 
1503 

.0093 
-.1637 

NONE 

.0110 

-.1552 

.0083 

0069 
0070 
0070 

6020 
1500 
1503 

.0093 
-.1718 

NONE 

.0110 

-.1702 

.0105 

0070 
0071 
0071 

6020 
1500 
1503 

.0109 
-.1718 

NONE 

.0110 

-.1702 

.0105 

0071 
0072 
0072 

oo2o 
1500 
1503 

.0109 
-.1718 

NOME 

.0110 

-.1702 

.0105 

0072 
0073 
0073 

6020 
1500 
1503 

.0109 
-.1713 

NOME 

.0110 

-.1702 

.C1C5 

0073 
0071^ 

6020 
1500 

.0109 
-.1718 

.0110  ' 
-.1702 

Sample  Model  by  Row  Listing 


U600   tJ250                     .2021 
Ji£Jlil_Jt25J .2R21 


1(600    (*&00  "X, 


«;601    t*2l8                     .0271 
1(601    «;250  ,0200 

t(6Dl   '(2'a3 .'PaSB 


U- 


«»60i  ^60l  -1.' 


1(602   «»2l8  .OBBl 

U602    1(250  .0936 

t(6Q2  ^^f^l .oqsfi 


1(602   1(252  .l2'(0 

1(602   1(602  -1, 


«(605   '(ZSO                     .0620 
t(6Qj   IPSJ ,0620 


u- 


((603   <(603  -1. 


«(60«(   «(252  .3262 

^60^  1(60'*  -i.' 


1(605   '(252                     .0813 
H6Q5   t(6n5 =JLJ 


((606    ^2S2 .1216 


C 


Ih 


«(606   4606  -1." 


«(607   '(351  .058U5 

^s      ■  t(607   £(607  -1," 


i(60B   1(360                    .0511(3 
^0£_  !L6.0Ji_ rL. 


Sample  MPS  Control   Program 


CONTROL    PROGRAM    COMPILER 


0001 

PROGRAM 

0002 

INITIALZ 

0057 

XFREQINV  =50 

0058 

XINVFRT  =  I 

O059 

MVAOR(XOONFS, INFEAS) 

«060 

MVAORCXDOUNR, MERTES) 

ooei 

MOVE ( XPRNAVE, "PRF ILE" ) 

^062 

MOVE (X OLD NAME. 'PSFILE' ) 

0063 

MOVE(XDATA,"NEWLP") 

0064 

RFVI SF( 'SUMMARY' ) 

0065 

SETUP { "BOUND", "ZZZZZZZZ", "MAX") 

0066 

MOVE(XOBJ . 'RWISOO • ) 

0067 

MOVE(XRHS,"ZZZZOOOl") 

0068 

MOVEC  XO AT A,  'BASIS' ) 

O069 

* 

BASIS  INSERT  BLCCK  (PRESENT  IF  OLD  BASIS) 

0070 

INSERT 

-0071 

GOTO(DOIT) 

-  0072 

* 

END  BASIS  INSERT  BLOCK 

0073 

CRASH 

0074 

DOIT 

PRIMAL 

0075 

SOLUTION 

0076 

PUNCH ( 'LIST', 'VALUE' ) 

—0077 

RANGE 

0078 

EXIT 

0075 

INFEAS 

TRACE 

ooeo 

MERTES 

STATUS 

ooei 

SOLUTION 

PUNCH  (  'LIST' , 'VALUE'  ) 

0082 

0083 

EXIT 

.0084 

PEND 

/ 

•• 

).   Portion  of  Sample  Iteration  Log 


ITER 

EXECUTOR. 
NUMBER   VECTOR 

VECTOR 

REDUCED 

FUNCTION 

NUMBER 

NONOPT 

OUT 

IN 

COST 

VALUE 

^ 

117 

1363 

1360 

.05646- 

2215. 1  I 

118 

1516 

1252 

.00004- 

2215.33 

M 

119 

35 

1728 

1663 

.03923- 

2217,28 

M 

120 

37 

12  52 

1207 

.01636- 

2217.50 

121 

1727 

1544 

.00235- 

2217.50 

**— ^ 

M 

122 

11 

1485 

14  85 

-00001 

2217.93 

123 

1207 

876 

.00001- 

2218. 13 

124 

782 

1711 

,   .00775- 

2218.16 

^. 

12S 

1656 

1652 

.00313- 

2?.  18.  17 

M 

126 

10 

1714 

1210 

>  .00426- 

2218. 19 

M 

127 

6 

11  86 

-1186 

.00000 

2218.42 

» 

128 

1185 

1185 

.00000 

2218.65 

129 

1412 

14  94 

.00000- 

2218.78 

130 

1573 

1574 

.01032- 

2218.80 

••^■ 

131 

-906 

746 

.00000- 

2218.81 

M 

132 

3 

1680 

1681 

.00041- 

2218.81 

133 

746 

759 

.00000- 

2218.82  . 

134 

1652 

1656 

.001 10- 

2218.82 

M 

135 

S 

759 

771 

.0  03  64- 

2218.84 

136 

1650 

1651 

.00041- 

2218.84 

- 

OPTIMAL 

SOLUTION 

, 

7.      Portion 

of   Sample 

MPS   Output    (Solution  Section) 

EXECUTOR. 

^y^»eEs 

.CCLUNN. 

AT        ,, 

•  ACTIVITY INPUT 

COST.. 

..LCteER    LIMT 

1222 

CL2706 

ES 

4C-C000C 

1223 

CL27C7 

LL 

40C.00CC0 

.25400 

400, 

.00000 

122A 

CL27Ca 

LL 

40.00000 

.27680 

40, 

.00000 

1226 

CL27C9 

LL 

60.00000 

.29000 

60. 

.00000' 

1226 

CL2720 

ES 

£69.e';4i4 

122T 

CL2751 

ES 

El7.C65Se       , 

122fl 

CL2722 
CL2723 

LL 

1229 

ES 

Z31.160CC 

1230 

CL2724 

LL 

•                                                < 

1231 

CL2725 

LL 

• 

1232 

CL272e 

ES 

133.95600 

1233 

CL2727 

LL 

.                                              « 

1234 

CL2728 

LL 

« 

1 

1235 

CL2729 

LL 

.                                              « 

1236 

CL2730 

ES 

35.12572 

1237 

CL2731 

ES 

143.46227 

S238 

CL2732 

ES 

87.32C0C 

1239 

CL2723 

LL 

•                                                                                              .,-4 

1240 

CL2734 

LL 

* 

m 

1241 

CL2735 

ES 

137.24CC0 

1242 

CL2736 

LL 

«                                                                                                     4 

1243 

CL2737 

LL 

•                                                                                                     4 

1244 

CL273e 

ES 

66.32400 

1245 

CL2739 

ES 

132.64600 

1246 

CL2740 

LL 

• 

1247 

CL274  1 

LL 

•                                                                                            \        ^ 

1248 

CL2742 

ES 

-     4<J.21<CC 

1249 

CL2743 

ES 

£23.92000 

12S0 

CL2744 

LL 

^  •                                                                                                     4 

12SI 

CL2750 

UL 

4C.C0CCQ 

.eeooo 

20, 

.00000 

1252 

CL2751 

UL 

8C.C0C00 

.56C00 

40. 

,  00000 

1253 

CL2752 

UL 

80.0CCCC 

.63000 

40. 

.  coooo 

12S4 

CL2753 

EQ 

•                                                                                                     4 

1              ^ 

1255 

CL2754 

UL 

120C.00C0C 

.53000 

600, 

.00000 

1256 

CL27S5 

UL 

200.00000 

.56000 

100. 

.00000 

1257 

CL275e 

UL 

12C-00000 

.52000 

60 

.00000 

1258 

CL27S7 

UL 

16C.0CC00 

.52000 

80. 

.00000 

1259 

CL275a 

UL 

8C.0CCC0 

.46000 

40. 

. ooooo 

1260 

CL2759 

UL 

120.00000 

.53000 

60. 

.00000 

1261 

CL27eO 

UL 

60.00000 

.47000 

20 

.ooooo 

1262 

CL27ei 

•UL 

120.00000 

.46000 

60 

,00000 

1263 

CL27e2 

,EQ 

4C.C0CC0 

.46000 

40, 

.ooooo 

1264 

CL27€2 

EQ 

48C.00CC0 

.41000 

480, 

, ooooo 

1265 

CL2764 

EO 

40C.O0CCO 

.36000 

400, 

.ooooo 

1266 

CL28S0 

ES 

196.22462 

.06750 

1267 

CL2e51 

ES 

62.ieC47 

,27000 

1266 

CL2e52 

ES 

32.01210 

.01550 

1269 

CL2e53 

ES 

241.51600 

.37000 

1270 

CL2eS4 

LL 

• 

.  15000 

1271 

CL3000 

ES 

72.C146«; 

1272 

CL3001 

ES 

ll£7.4€^9e 

» 

, 

-  -          -'                              .-          -j.^     _ 

." 

-—    •  -- 

PAGE 


39       - 


67/312 


••UPPER    LIMIT. 


.REDUCED    COST, 


^«J«><}9.00  00  0 

600.00000 

,02116- 

1 

S20. 00000 

,00433- 

120.00000 

,06127- 

99999.00000             . 

99999-00000 

9<><>Q«J.  00000 

99999.00000 

^9999.00000 

99999.00000 

99999.00000 

99999.00000 

j> 

99999.00000 

99999.00000 

99999-00000 

. 

99999.00000 

99999.00000 

-99999.00000 

-99999,00000 

99999.00000 

99999.00000 

99999.00000 

-99999.00000 

•99999.00000 

-99999.00000 

99999.00000 

•  -^   99999.00000 

99999,00000 

' 

99999.00000 

♦0.00000 

.15581 

80.00000 

.10847 

80.00000 

.08077 

• 

.46691- 

-1200.00000 

,09804 

200.00000 

.09906 

' 

120.00000 

.0871 0 

160.00000 

,  103flf 

80.00000 

.04571 

120.00000 

.15766 

" 

60-00000 

,  1007? 

120.00000 

,10538 

AO. 00000 

.11243 

480.00000 

.04239 

-400.00000 

.00366 

99999.00000 

•99999.00000 

99999.00000 

99999.00000 

99999.00000 

.01141- 

99999.00000 

99999.00000 

8.      Portion  of   Sample  MPS   Output    (Ranges   Section) 


EXECUTOR. 


U>EEK        •CCLUA'N.        ^T        .  •  •  ^CT  I V  ITY  •  • 


•INPUT    COST,.        ..LCUER     LIVIT 

••UPPER    LIMIT 


1214 

CL26£€ 

LL 

• 

• 

• 
99998.94830 

1216 

CL27C0 

U. 

3S.99^94 

\ 

•46C00 

\ 
\ 

19.99997 
39.99995 

1217 

CL27C1 

LU 

• 

.Z90CC 

• 
39.99999 

1216        CL270: 


LL 


19«.S9«e3 


.33240 


199.99983 
399.99981 


1219        CL27C3  LL 


\ 


1  199  .9990  1 


,33340 


1199.99901 
1599.99877 


1220        CL27C4  LL 


199.99963 


,23340 


199.99983 
399.99981 


1221 

CL27C5 

LL 

• 

• 

• 

99998.94830 

1223 

CL27C7 

LL 

299.99982 

•2S40C 

399-99982 
599.99981 

1224 

CL27Ce 

LL 

39.99999 

•27eec 

39.99999 

119-99998 


122S 

CL2709 

LL 

S9.99994 

•2900C 

59.99994 
119.99993 

1226 

CL2722 

LL 

• 

• 

• 
99998.94830 

1230 

CL2724 

LL 

• 

J 

• 

• 

99998.94830 

1231 

CL2725 

LL 

• 

• 

• 

99998.94830 

1233 

CL2727 

LL 

• 
1 

• 

• 

99998.94830 

1234 

CL272e 

• 

LL 

• 

• 

m 

99996.94830 

X23S 

CL2729 

LL 

• 

• 

• 

99998.94830 

1239 

CL2722 

LL 

• 

• 

• 

99998.94830 

PACE 


1?4       -        67/312 


CCWEB  ACTIVITY    ...UNIT 
UPPER  ACTIVITY   ...UNIT 

COST.. 
COST.. 

..UPPER  COST.. 
..LOVIFR  COST.. 

LI  MI  TI  KG 
PROCFSS. 

AT 
AT 

617.06519- 

• 

INFINITY- 

• 

CL2721 
CL2659 

LL 
LL 

34.58343 
123.49658 

•1356  3- 
,13563 

-32437 
INFINITY 

CL2251 
CL2251 

LL 

UL 

• 
l<». 70951 

,06463 
,06463- 

INF  INI  TY- 
.35463 

CL2fi50 
CL2600 

LL 
LL 

458.41723- 
780.10356 

.00400 
►00400- 

INFINITY- 
.33740 

CL2256 
CL2720 

LL 
LL 

S41. 58247 
2204.46788 

»00400 
,0040  0- 

INF  IN  IT  Y- 
. .33740 

CL2256 
CL2256 

LL 

UL 

164.24483 
346.05  260 

,00400 
,00400- 

INFINITY- 
.33740 

CL2730 
CL2731 

LL 
LL 

!<;. 78978- 
39.99997 

INFINITY- 

• 

CL2602 
CL2706 

LL 
LL 

448.80744- 
A96.76113 

.0211€ 
, 021 16- 

INFINITY- 
.27£1€ 

CL2657 
CL2603 

LL 
LL 

«                   -< 
-^9.T8978 

,00433 
.00433- 

INFINITY- 
.28313 

CL2706 
Cl.2602 

LL 
LL 

'55.20400 
133.93223 

.06127 
.06127- 

INFINI TY- 
.35127 

CL2251 
CL2251 

LL 
UL 

35.12570- 
-143.48219 

INFINITY- 

• 

CL2730 
CL2731 

LL 
LL 

569.89365- 
.231.15988          '   . 

INFINITY- 

• 

CL272  0 
CL2723 

LL 

LL 

35.12570- 
443.48219 

INFINITY- 

• 

CL2730 
CL2731 

LL 
LL 

569.89365- 
133.95591 

: 

INFINITY- 

• 

CL2720 
CL2726 

LL 
LL 

35.12570- 
-L33-9559  1 

INFINITY- 

• 

CL2730 
CL2726 

LL 
LL 

€17.06519- 
35.12570 

INFINITY- 

CL2721 
CL2730 

LL 
LL 

569.89365- 
87.31994 

INFINITY- 

• 

CL272  0 
CU273? 

LL 
LL 

9.   Sample  Output  of  "Update  B-Solution"  and  "Report" 


L.P. 
Col. 
No. 

, 

-p 
o 

< 

Description 

U 

< 

Recornm( 
Acti' 

3nded                R« 
^ty                 .  ( 

jduced 
:k>st 

3301 
0302 

bB   d    «-12   HAMS    (A   PfaCE) 
.    SL<.i3    t-12    HAnS    (i3    PKICE)    _ 

LL 
LL 

,00500- 
,02000- 

03u3 
03JU 
_   0305_ 

SI3    B 
SB  a 

sn  13 

b3    u 

sn  li 
so  d 

SL»   o 
SB    U 
SB   li 
SO  u 
SB   b 

sb"'u 

SB   li 
SB   L> 

SB  a 

SB    B 
SB   B 
:*u'b 
SB    B 
SB    B 
Sb    S 
SB    S 
SB    S 

SB'S 

SB    S 
SB    3 
SG    S 
SB    S 
SB    S 
'   "SB'S 
SB    S 
SB    S 
SB    S 
SB   S 
SB    S 

"so  s 

SB    S 

SB    I 

■■"'SB    I 

12-l'^   rlA.".S    (A   PRICE) 

12-14    HAWS    (B    Hr<lCE) 

Jt^-rie   ItAtuS    (A^PKICE) 

LL 
LL 
1  L 

,00500- 
,01500- 
.nfi64i- 

03ur> 

■  0307 

03UA 

14-16    HAMS    (B    P>nCE). 
16-lt»    HAMS    (A    PKICE) 
16-18   HAMS    (B    PRICE) 
16-20    hAl!S    (A    PUICE) 
lfl-20    HAMS    (B   PKICE) 
20-22    HAMS    (A    PRICE) 

LL 
LL 
LL 

•01641- 

.       ^00970- 

•02470- 

03o9 
0310 
0311 

LL 

,      LL 

UL 

207, 

•00970- 
►     •                       ♦02470- 
,000                    .00512 

031?. 
C313 
031^+ 

2  0-22    liA.-'.b    (B    PRICE) 
22-24    HAMS    (A    PRICE) 
22-24    HA[-;S    (H    PRICE) 
"24-26    HAMS    <"A    PRICE) 
24-26   P.Ai-iS    (B    PRICE) 
26-30    Hams    (A    PRICE) 

LL 
LL 
LL 

,'   ■                       •00408- 
•00870- 
.01470- 

0315 

w  0316 

0317 

•    LL 
LL 
LL 

'  •                        " 

,00970- 
,01970- 
,00970- 

Oiia 

0319 
03cl0 

26-30    HAiVS    (B    PRICE) 
30-35    HA.'IS    (A    PRICE) 
30-35   \iM:S    (B   PRICE) 
'35-UP'ilA;;S    (A    PRICE) 
35-UP    HAriS    (E)    PRICE) 
2b-B0WU    2    CJ    HAMS 

LL 

•     LL 

LL 

,02470- 
,00500- 
,01000- 

03'Jl 

-03iLii 

03^3 

LL 
LL 
£0 

3o! 

47. 
24ft 
115 
303 

60 

.600 

,00500- 
,01000- 
,01279 

03L,0 
03ol 
03o2 

i^-12    OH    SK    HAM 
12-14    GR    SK    HAK 
14-16    GR    SK    HAM    SKR 
'"14-16    Grr<  "SK    HAM'FLTR' 
16-ie    GR    SK    HAf.    SKR 
16-in    GR    SK    hAi«.    FLTR 

BS 
BS 
BS 

es" 

LL 
BS 

.255 
.715 

.003 

m   .      '•         '• 

03h3 
03u4 
03b5 

.619 
.021 

03t»t> 
03t)7 
03t>rt 

16-20    GR    SK    HAM    SKR 
18-20    GR    SK    HAM    FLTR 
20-22    GR    SK    HAM    SKR 

BS 
LL 
LL 

09 

.864 

,01674- 

03by 

03on 

iJ3ul 

20-22    GR    SK    HAM   FLTR 
r.2-24    GR    SK    HAM 
24-26    GR    SK    HAM 
26-30    GR    SK    HAM    . 
30-35    Gk    SK    HAM 
35-UP    GR    Sn    HAM 

LL 
BS 
BS 
3S 
LL 
LL 

200 
265 

[451 
.750 

.0^700- 

C3o2 
0363 
C3o'^ 

36 

,162 

.00470- 
,00470- 

C3oS 

^  0^01 

2    25-DOWN    GR    SK    HAMS      LL 

2   25-U?    6R    SK   HAMS           LL 

e-12    HAMS                                       LL 

, 

,01749- 
,04012- 
,00470- 

o^u? 

12-14    HAMS 

LL 

i   ■               *                                      i 

,00470- 

nif  < .  'a 


•  I »  ••<- 


r\^»»^  f\ 


Greatest 
■  Cost 

"UadLt 


limiting 
Activity 


At. 


T7T 


i  ■'   I 


•47500 

•UU500 

_.*|250  0_ 

.30799 


CL0450 

CL0'+51 

CL0466 

"CL0507 


.40000 CL035fL 


.39500         CL0357 


UL 
UL 
LL 
LL" 

_LL_ 
LL 


.48000 
.45000 
.42500 
.44637 

.40065 
.39705" 


CL0301 
CL0303 
CL0405 
CL0305 

CL0777 
CL0514 


LL 
LL 
LL_ 
LL 

_LL_ 
LL 


.37600 

_i37^D_g.O. 

•355U0 


CL0411 

CL04_1_2 

'CL04'l3' 


LL 
LL 


.3Q242 

.37800 

"•35970 


CL0514 
CL0672 
CL0458 


LL 

LL_ 

LL 


1  > 


10 

, 

Sample   Output 

of   "Report   Solution  Changes" 

005t; 

3 

H 

LVE 

WGT 

HOGb 

2BU-J00G;i 

bS 

181.027 

OdS"^ 

r\ 

H 

LVE 

••;gt 

•rpr,b 

2a()-3noG'+ 

3S 

13'J.'+63 

0055 

1) 

ft 

L\/E 

WGT 

H^GS 

aOu-300G^. 

BS 

266.5.12 

005'^ 

A 

H 

L\/E 

:Vr,T 

H055 

23J-500G5 

JS 

106.919 

0056 

6 

H 

LVE 

WGT 

H^Gb 

2au-J0uG5 

J  5 

233.129 

0057 

A 

H 

L^/E 

WGT 

M^D'nS 

2Sij-jni)G6 

>iS 

374.529 

0ud7 

d 

r\ 

LVE 

WGT 

HOGS 

2:JJ-30oG6 

:js 

86'l.l2t 

005'^ 

A 

H 

LVE 

WGT 

hjgg 

30U-320G1 

3S 

•                                                         • 

• 

005*^ 

d 

H 

LVE 

WGT 

HOGS 

30j-J2oGl 

dS 

'+.no'4 

005P 

A 

H 

LVE 

■VGT 

H'-Jr^S 

30n-320G2 

■HS 

3.744                    .          ! 

00^9 

CJ 

H 

LVE 

WGT 

\r\OQ^ 

30J-320G2 

3S 

5.336 

> 

0060 

A 

H 

LVE 

WGT 

Hor.s 

300-320G3 

3S 

22.737 

1 

0U60 

D 

H 

LVE 

WGT 

HUGS 

300-320G3 

B5 

55.301 

1 

0061 

A 

H 

LVE 

WGT 

hOgs 

300-320G4 

5S 

25.272 

1 

1 

OUol 

bi 

H 

LVE 

WGT 

HUGS 

300-320GI+ 

bS 

63.879 

005? 

H 

LVE 

WGT 

HOGS 

300-320G5 

iiS 

30.441 

i 

0062 

a 

H 

LVE 

WGT 

HOGS 

30o-:;2GG5 

3S 

89.705                    .          j 

1 

0063 

A 

H 

LVE 

WGT 

h^gs 

300-320G6 

:iS 

133.055                    .          ! 

I 

0063 

a 

H 

LVE 

WGT 

HOGS 

300-320G6 

dS 

386.663 

0061* 

A 

H 

LVE 

WGT 

HOGS 

32U-34UG1 

LS 

1.324                    .    ■ 

; 

OOb^ 

6 

ri 

LVE 

WGT 

HOGS 

320-340G1 

BS 

1.293                    .         j 

006S 

A 

H 

LVE 

WGT 

H0(;S 

32u-3'J-0G2 

[jS 

2.764                    .          i 

, 

0065 

3 

ri 

LVE 

WGT 

H^GS 

32U-3'+0G2 

aS 

2.541                    .          1 

t 

0066 

n 

H 

LVE 

WGT 

HOGS 

32U-340G3 

BS 

4.017 

- 

0066 

J 

H 

LVE 

WGT 

HOGS 

32U-3UUC3 

JS 

6.2b7 

i 

0067 

A 

4 

LVE 

•A'GT 

hO:,s 

52u-3'+uGt^ 

5S 

9.532 

1 
i 

0067 

Zi 

!l 

LVE 

WGT 

HOGS 

32u-3'^0G'+ 

-jS 

23.BU8                    .         1 

i 

006^ 

A 

H 

LVE 

WGT 

mOgs 

32Ur3'^0G5 

o5 

8.107                    .         1 

1 

) 

OooR 

3 

H 

LVE 

vJGT 

h0g:3 

320-340G5 

:iS 

26.457                   .         i 

i 

0c69 

A 

H 

LVE 

WGT 

i-JOGi 

32u-3ilOGb 

H5 

37.728                   .         ! 

0069 

i 

d 

LVE 

WGT 

HOGS 

320-3'+0G6 

:,S 

lCb.262                   .         ; 

0070 

A 

•1 

LVE 

WGT 

p<;>s 

30b!:CWi\Gl 

:;5 

71.611                     .         1 

1 

0070 

L> 

H 

LVE 

WGT 

Prv-^S 

3GuD0WnG1 

dS 

78.001                    .          1 

1 

! 

Cu71 

a 

H 

LVE 

WGT 

PKUi, 

30fiDOW,MGci 

■)S 

99.331 

i 

0071 

3 

H 

LVE 

WGT 

P^Rb 

3j00OWMG2 

-s  ■ 

70.054                     .          ; 

1 

0j7? 

»n 

H 

LVE 

wr.T 

PfSl'S 

30uTOWNjG3 

-.5 

46.713                    .         ■ 

1 

00  72 

3 

H 

LVE 

wsv 

P^^^S 

3Ju'J0 '7,\iG3 

•jS 

56.394 

0073    A      H    LVE    WGT    p-'.-L,    30uTOW,MG4    jS  12. '484 


Sample  Output   of    "Report  Solution  Changes" 


5.19751-      CLOOOl  UL  INFINITY 

8.21026-      CL0002  UL  INFINITY 


NONE 
N0N5^ 


3.563o5-   CLOOOl     UL     INFINITY 
10.65011-   CL0n02     UL     INFINITY 


NONE 
NONE 


3.3P30B-   CLOOOl     UL     INFINITY 
3.16277-   CLOnn^     UL     INFINITY 


NONE 
NONE 


1.22011*-   CLOOOl     UL     INFINITY 
INFINITY-       NONE         INFINITY 


NONE 
NONE 


189.72670-   CLOOOl     UL     INFINITY 
299.73600-   CL0002     UL     INFINITY 


NONE 
NONE 


156.215^7-   CLOOOl     UL     INFINITY 
t9.U9'*12-   CL0002     UL     INFINITY 


NONE 
NONE 


16.63221-   CLOOOl     UL     INFINITY 
41.5H730-   CL0002     UL     INFINITY 


NONE 
NONE 


lt.'^20b3■ 
3.  .01056- 


CLOOOl 
CL0002 


UL 
UL 


INFINITY 
INFINITY 


INFINITY 
INFINITY 


NONE 
NONE 


10.31561- 

9.59597- 


CLOOOl 
CLn002 


UL 

UL 


NONE 


2.51769- 
BH6. 77575- 


CLOOOl 
CLn002 


UL 

UL 


INFINITY 
INFINITY 


NONE 
NONE 


70'!. 26055- 
^05.63lBt|- 


CLOOOl 
CL0002 


UL 
UL- 


INFINITY 
INFINITY 


NONE 


MONE 


358.61285- 
279.33320- 


CLOOOl 
CL0002 


UL 
UL 


INFINITY 
INFINITY 


NONE 
NONE 


m5.Ua059- 
117.ni976- 


CLOOOi 
CLn002 


UL 
UL 


INFINITY 
INFINITY 


NONE 
NONE 


38.1*1946- 
13B.50B04- 


CLOOOl 
CL0002 


UL 
UL 


INFINITY 
INFINITY 


NONE 
NONE 


3«+,5B939- 
29.892C6- 


CLOOOl 
CL0002 


UL 

UL  \ 


INFINITY 
INFINITY 


NONE 

NONE 


8,57631- 

CLOOOl 

UL 

\   INFINITY 

NONE 

15.B34L"4- 

CL0n02 

UL 

\  INFI>IITY 

NONE 

ll.G33b^- 

CLOOOl 

UL 

INFINITY 

NON=: 

11.46^23- 

CL0nn2 

UL 

INFINITY 

NONE 

13.163UH- 

CLOoni 

UL 

INFINITY 

NONE 

24. 1''.  177- 

CLn002 

UL 

INFINITY 

NOME 

16.3122B- 

CLonoi 

UL 

INFINITY 

NONE 

90.00?:i7- 

CLnoo2 

UL 

INFINITY 

NONE 

11.   Sample  Output  of  "Monitor  Inconsistencies" 


'0306. 

^0366 

".f6 
.0 

k     j 

a' 

s 

14-16  HAMS  (3  PRICE) 
2  ?5-UP  GR  SK  HAMS 

inconsistent 
inconsistent 

0660 
3613 
»nno 

.0 
0*0 
n. 

p 
p 
I 

1«+-16.  SMOSKLS  WA  FC  HM 
FRESH  PICNIC  CHUNKS 
lL-18  REG  LN 

INCONSISTENT 
INCONSISTENT 
INCONSISTENT 

3015 
8017 
80?0 

-99.99 
-99.99 
-qq.9q 

INCONSISTENT 
INCONSISTENT 
INCONSISTENT 

8050 
8059 
8060 

-99.99 
-99.99 
-99.99 

INCONSISTENT 
INCONSISTENT 
INCONSISTENT 

3061 
8065 
8121 

-99.99 

-99.99 

0. 

20%    PK  TRiVI  (21) 

INCONSISTENT 
INCONSISTENT 
INCONSISTENT 

8122 

^  sito 

8l«t2 

0. 
0. 
0. 

Picnic  trim  (22) 

^0%    LEAN  BF  (*+0) 
85*  QF  ChO  BRIS  ('+2) 

INCONSISTENT 
INCONSISTENT 
INCONSISTENT 

QU5 
8152 
8158 

0. 
0. 
0. 

60Ji  LEAN  BEEF  C+S) 
70;^  LEAN  BF  (52) 
20«  PK  TRIM  (5S) 

INCONSISTENT 
INCOMSISTENT 
INCONSISTENT 

8167 
3266 

1 

0. 
^  .f22l 

0 

Boit  LEAN  BF  (67) 

Pic  chunks  (66) 

INCONSISTENT 
INCONSISTENT 

0022  INCONSISTENT         NO  DESCRIPTION 

2 
u 

U 

ce 


S         -^ 


ii 


8  .2 


(/)     3     <0 

3  E   ' 


:     ^ 


.5 


■2 


■5 


BT 

«1 

C 

3 

^S 

« 

^ 

c  s 

J 

c« 

3 

E 


1 
Q 


^ 
o 
n 
•«»• 


i^^^^S: 


Ul  lA  1     I    •' 


Date  Due 

^ 

out  6  It 

APR02'^ 

AG  1  S  -33 

1 
1 

Lib-26-67 

Ilil|iii|!;sii;liliii«rni|'"ii'"    ^„ 
3   TOaO   D03   70 


1^^1.70 


E    237 


niiT.  liliiii'lM 


l^^l 


^70 


',   3TDfiO   003    702    211 


r  ilB«»»It5  »"" 


q^^'lOA 


^DfiD    DD3    b71    200 


M  T. 


Mil    .18«»«1"  „,  ,,|| 


■iiippiiii"«i"''""*""'":'"iv  PUP 

3 10"  °"  '^'ii'. 


f 


fp/ziftef'te 


V'/^ 


./v?'-^'^ 


3    =1060   003   b71    35fi 


'*:''  lIBbabies  oupl 


3    TOflO    0 


■y*/^'^ 


3    702    34^ 


3    lOfiD    0 


MH  LIBRARIES  OUPL 


3    702    31 


L/i^^--7J> 


MIT   LIBR*SIES  OUPL 
■■■■Illlll--- ■ 


3    ^DSD    0 


^y? 


70 


3    b71    3DT 


MIT  LIBRARIES  .  O^P'. 


3  TOfiO  0 


II  ^5/ '70 


03  b71  325 


3  lOfiO  003  L.71  333 


